date:20180802

>>> On 02.08.18 at 00:20,  wrote:
> On Tue, Jul 31, 2018 at 05:25:27AM -0600, Jan Beulich wrote:
>> Code structure wise this looks to undo a fair part of what patch
>> 1 has done. It would be nice to limit code churn.
> 
> Patch 1 stand alone just to improve reporting the capabilities of the
> processor.  Currently Xen doesn't mention anything if SSBD is actually
> enable on AMD processors.  Patch 2-3 add it where Xen can it
> dynamically.

Which is all fine, but couldn't patch 1 be written in a way that the
next one(s) don't have to turn code structure all over again.

>> Why can't this be called from init_speculation_mitigations()?
> 
> IIRC I was having memory init problems with.  It was moved to later in
> the boot so that xmalloc would work correctly.  I haven't touched this
> code in over month.  If you want a 100% tested answer I can retest
> putting it in init_speculation_mitigations().

Would be nice if that could be arranged for, as the rather specialized
call looks pretty odd in (iirc __start_xen(); iirc because you've dropped
too much of the context in your reply, and I'm too lazy to dig out the
original patch again).

>> You really should notice such anomalies / inconsistencies yourself:
>> You properly use uint64_t here, so why not also uint32_t on the
>> preceding line? That said - why a fixed width type anyway for
>> those variables - unsigned int looks to be just fine there.
> 
> IIRC they're __32 in struct I'm reading from so I decided to use that.
> I can change them though, that's easily.

Thanks - we prefer to avoid u and s in favor of uint_t
and int_t in new code, and __u as well as __s should
go away rather sooner than later anyway, as representing name
space violations (__s8, for example, already looks to be unused).

>> This function is called from exactly one place, with the
>> parameter set to true. Makes me wonder what the actual
>> purpose of this patch is.
> 
> See earlier in this email.

Where? I can't find anything as to the purpose. Your response to
patch 1's comments on mine might have been a hint, but then again
the function parameter here seems contrary to the alternatives
patching plans, at least at the first glance. If you want to keep
the parameter (rather than introducing it when needed), please at
least outline the plans in the description.

>> Still I wonder whether less code duplication wouldn't be better.
> 
> current_cpu_data isn't available when ssbd_amd_ls_cfg_init is called.

By "isn't available" you mean "hasn't been populated yet"? Else
I don't understand.

>> I find such a hard-coded upper bound quite concerning. Is nr_sockets
>> not correct in the AMD case? If so, that would want fixing, such that
>> you can use the variable here.
> 
> It's been a while since I wrote this but IIRC, it has to do with
> nr_sockets either being off or not available when the code is run.
> For Family 17h which the patches are for, there's a max of two sockets.

I've implied that from how you wrote the patches, but such hard coding
will only make for more code churn later on. Try to be as generic as
possible.

>> Btw - why the xen_ prefix for the variable?
> 
> See the first reply, but basically it's for if Xen has SSBD turned on
> or not via using the LS_CFG MSR.

Personally I'd prefer if the xen_-prefixed sub-name-space was left to
the public interface. Make it an infix if you want to express what you've
explained?

Jan

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

Re: [Xen-devel] [PATCH] x86/vmx: Avoid hitting BUG_ON() after EPTP-related domain_crash()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 1, 2018 8:08 PM
> 
> If the EPTP pointer can't be located in the altp2m list, the domain
> is (legitimately) crashed.
> 
> Under those circumstances, execution will continue and guarentee to hit
> the
> BUG_ON(idx >= MAX_ALTP2M) (unfortunately, just out of context).
> 
> Return from vmx_vmexit_handler() after the domain_crash(), which also
> has the
> side effect of reentering the scheduler more promptly.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

>>> On 01.08.18 at 15:40,  wrote:
> ...to simplify the implementation and turn need_iommu back into a boolean.
> 
> As noted in [1] the tri-state nature of need_iommu after commit 3e06b989 is
> confusing, as is the implementation of pre-emption using relmem_list.
> 
> This patch instead uses a simple count of pages already populated stored in
> the x86 variant of struct arch_iommu and skips over that number of pages
> if arch_iommu_populate_page_table() is re-invoked after pre-emption.

Well, yes, I would have used that model in said commit if it was reliable,
but it isn't: What if the list of pages changed between two (re-)invocations?
Furthermore, with huge enough a guest even the skipping of the already
processed several million pages may exhaust the time acceptable between
preemption points.

Jan

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

Re: [Xen-devel] [PATCH] x86/vmx: Avoid using domain_crash_syncrhonous() in vmx_vmentry_failure()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 1, 2018 8:55 PM
> 
> There is no need for the syncrhonous varient, as the vmentry failure path
> can
> just return to processing softirqs.
> 
> This is in aid of trying to remove domain_crash_syncrhonous() from the
> codebase.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2 1/5] iommu/vtd: cleanup vtd_set_hwdom_mapping after ia64 removal

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, August 1, 2018 7:04 PM
> 
> Remove the handling for different page sizes now that ia64 is gone.
> 
> No functional change.
> 
> Reported by: Jan Beulich 
> Signed-off-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu option

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, August 1, 2018 7:04 PM
> 
> To select the iommu configuration used by Dom0. This option supersedes
> iommu=dom0-strict|dom0-passthrough.
> 
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v1:
>  - New in this version.
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Suravee Suthikulpanit 
> Cc: Brian Woods 
> Cc: Kevin Tian 
> ---
>  docs/misc/xen-command-line.markdown | 32 ++
>  xen/arch/x86/x86_64/mm.c|  3 +-
>  xen/drivers/passthrough/amd/iommu_init.c|  2 +-
>  xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 +-
>  xen/drivers/passthrough/iommu.c | 46 +
>  xen/drivers/passthrough/vtd/iommu.c | 16 +++
>  xen/include/xen/iommu.h |  6 ++-
>  7 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-
> command-line.markdown
> index 65b4754418..a2a07cc6c8 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1150,12 +1150,18 @@ detection of systems known to misbehave
> upon accesses to that port.
> 
>  > `dom0-passthrough`
> 
> +> **WARNING: This command line option is deprecated, and superseded
> by
> +> _dom0-iommu=none_ - using both options in combination is
> undefined.**
> +

in patch description you said 'supersede'... is it better to say that
new dom0_iommu is favored if both options are specified than
saying 'undefined'?

>  > Default: `false`
> 
>  >> Control whether to disable DMA remapping for Dom0.
> 
>  > `dom0-strict`
> 
> +> **WARNING: This command line option is deprecated, and superseded
> by
> +> _dom0-iommu=strict_ - using both options in combination is
> undefined.**
> +
>  > Default: `false`
> 
>  >> Control whether to set up DMA remapping only for the memory Dom0
> actually
> @@ -1198,6 +1204,32 @@ detection of systems known to misbehave upon
> accesses to that port.
> 
>  >> Enable IOMMU debugging code (implies `verbose`).
> 
> +### dom0-iommu
> +> `= List of [ none | strict | relaxed ]`
> +
> +> Sub-options are of boolean kind and can be prefixed with `no-` to effect
> the
> +> inverse meaning.

not important comment, but doesn't "no-none" sound weird? :-)

> +
> +> `none`
> +
> +> Default: `false`
> +
> +>> Control whether to disable DMA remapping for Dom0.
> +
> +> `strict`
> +
> +> Default: `false`
> +
> +>> Control whether to set up DMA remapping only for the memory Dom0
> actually
> +>> got assigned.
> +
> +> `relaxed`
> +
> +> Default: `true`
> +
> +>> Controls whether to setup DMA remappings for all the host RAM
> except regions
> +>> in use by Xen.
> +
>  ### iommu\_dev\_iotlb\_timeout
>  > `= `
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index cca4ae926e..84226b3326 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1426,7 +1426,8 @@ int memory_add(unsigned long spfn, unsigned
> long epfn, unsigned int pxm)
>  if ( ret )
>  goto destroy_m2p;
> 
> -if ( iommu_enabled && !iommu_passthrough
> && !need_iommu(hardware_domain) )
> +if ( iommu_enabled && !iommu_dom0_passthrough &&
> + !need_iommu(hardware_domain) )
>  {
>  for ( i = spfn; i < epfn; i++ )
>  if ( iommu_map_page(hardware_domain, i, i,
> IOMMUF_readable|IOMMUF_writable) )
> diff --git a/xen/drivers/passthrough/amd/iommu_init.c
> b/xen/drivers/passthrough/amd/iommu_init.c
> index 474992a75a..ad8c48be1c 100644
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1062,7 +1062,7 @@ static void __init amd_iommu_init_cleanup(void)
>  radix_tree_destroy(&ivrs_maps, xfree);
> 
>  iommu_enabled = 0;
> -iommu_passthrough = 0;
> +iommu_dom0_passthrough = false;

ah, I see why "undefined" was used earlier. Both options control same
variable, thus the behavior is undefined when both are specified. If that
is the case, possibly clearer to say " This option *deprecates* iommu=
dom0-strict|dom0-passthrough" in patch description?

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

Re: [Xen-devel] [PATCH net-next] xen-netback: use true and false for boolean values

On Wed, Aug 01, 2018 at 07:31:01PM -0500, Gustavo A. R. Silva wrote:
> Return statements in functions returning bool should use true or false
> instead of an integer value.
> 
> This issue was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Wei Liu 

Thanks for the patch.

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

Re: [Xen-devel] [PATCH v2 3/5] iommu: make iommu_inclusive_mapping a suboption of dom0-iommu

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Wednesday, August 1, 2018 7:04 PM
> 
> Introduce a new dom0-iommu=inclusive generic option that supersedes
> iommu_inclusive_mapping. The prevcious behaviour is preserved and the
> option should only be enabled by default on Intel hardware.
> 
> No functional change intended.

there is functional change. Original condition is:

 -if ( !iommu_dom0_passthrough && is_pv_domain(d) )
 -{
 -/* Set up 1:1 page table for hardware domain. */
 -vtd_set_hwdom_mapping(d);
 -}

Now it is always called.

> 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v1:
>  - Use dom0-iommu instead of the iommu option.
>  - Only enable by default on Intel hardware.

[...]
> 
> +void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
> +{
> +unsigned long i, top, max_pfn;
> +
> +BUG_ON(!is_hardware_domain(d));
> +
> +/* Set the default value of inclusive depending on the hardware. */
> +if ( iommu_dom0_inclusive == -1 )
> +iommu_dom0_inclusive = boot_cpu_data.x86_vendor ==
> X86_VENDOR_INTEL;
> +

I don't like above style. 

btw It's better to set it in intel_iommu_hwdom_init.

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

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 August 2018 08:20
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel  de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim (Xen.org) 
> Subject: Re: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make
> page table population preemptible"...
> 
> >>> On 01.08.18 at 15:40,  wrote:
> > ...to simplify the implementation and turn need_iommu back into a
> boolean.
> >
> > As noted in [1] the tri-state nature of need_iommu after commit 3e06b989
> is
> > confusing, as is the implementation of pre-emption using relmem_list.
> >
> > This patch instead uses a simple count of pages already populated stored in
> > the x86 variant of struct arch_iommu and skips over that number of pages
> > if arch_iommu_populate_page_table() is re-invoked after pre-emption.
> 
> Well, yes, I would have used that model in said commit if it was reliable,
> but it isn't: What if the list of pages changed between two (re-)invocations?

Is that really going to happen? This is the result of a domctl, which is a 
tools-only hypercall right?

> Furthermore, with huge enough a guest even the skipping of the already
> processed several million pages may exhaust the time acceptable between
> preemption points.

Ok, I'll keep a pointer into the page list instead.

  Paul

> 
> Jan
> 


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

Re: [Xen-devel] [PATCH v2 5/5] x86/iommu: add PVH support to the inclusive options

> From: Roger Pau Monne
> Sent: Wednesday, August 1, 2018 7:04 PM
> 
> Several people have reported hardware issues (malfunctioning USB
> controllers) due to iommu page faults on Intel hardware. Those faults
> are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
> be worked around on VTd hardware by manually adding RMRR entries on
> the command line, this is however limited to Intel hardware and quite
> cumbersome to do.
> 
> In order to solve those issues add a new dom0-iommu=reserved option
> that identity maps all regions marked as reserved in the memory map.
> Note that regions used by devices emulated by Xen (LAPIC, IO-APIC or
> PCIe MCFG regions) are specifically avoided. Note that this option is
> available to a PVH Dom0 (as opposed to the inclusive option which only
> works for PV Dom0).
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v1:
>  - Introduce a new reserved option instead of abusing the inclusive
>option.
>  - Use the same helper function for PV and PVH in order to decide if a
>page should be added to the domain page tables.
>  - Use the data inside of the domain struct to detect overlaps with
>emulated MMIO regions.
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  docs/misc/xen-command-line.markdown |  9 +++
>  xen/arch/x86/hvm/io.c   |  5 ++
>  xen/drivers/passthrough/iommu.c |  3 +
>  xen/drivers/passthrough/x86/iommu.c | 88 +---
> -
>  xen/include/asm-x86/hvm/io.h|  3 +
>  xen/include/xen/iommu.h |  2 +-
>  6 files changed, 86 insertions(+), 24 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-
> command-line.markdown
> index 30d970bc2e..526a96ffc5 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1241,6 +1241,15 @@ detection of systems known to misbehave upon
> accesses to that port.
>  >> applicable to a PV dom0. Also note that if `strict` mode is enabled
>  >> then conventional RAM pages not assigned to dom0 will not be mapped.
> 
> +> `reserved`
> +
> +> Default: `true` on Intel hardware, `false` otherwise
> +
> +>> Use this to work around firmware issues providing incorrect RMRR or
> IVMD
> +>> entries. Rather than only mapping RAM pages for IOMMU accesses for
> Dom0,
> +>> all memory regions marked as reserved in the memory map that don't
> overlap
> +>> with any MMIO region from emulated devices will be identity mapped.
> +
>  ### iommu\_dev\_iotlb\_timeout
>  > `= `
> 
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> index bf4d8748d3..5e01c33890 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -404,6 +404,11 @@ static const struct hvm_mmcfg
> *vpci_mmcfg_find(const struct domain *d,
>  return NULL;
>  }
> 
> +bool vpci_mmcfg_address(const struct domain *d, paddr_t addr)
> +{
> +return vpci_mmcfg_find(d, addr);
> +}
> +
>  static unsigned int vpci_mmcfg_decode_addr(const struct hvm_mmcfg
> *mmcfg,
> paddr_t addr, pci_sbdf_t *sbdf)
>  {
> diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> index 6611e13cc2..a3eb7c5b7f 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -75,6 +75,7 @@ custom_param("dom0-iommu",
> parse_dom0_iommu_param);
>  bool __hwdom_initdata iommu_dom0_strict;
>  bool __read_mostly iommu_dom0_passthrough;
>  int8_t __hwdom_initdata iommu_dom0_inclusive = -1;
> +int8_t __hwdom_initdata iommu_dom0_reserved = -1;
> 
>  DEFINE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
> 
> @@ -161,6 +162,8 @@ static int __init parse_dom0_iommu_param(const
> char *s)
>  iommu_dom0_strict = !val;
>  else if ( !strncmp(s, "inclusive", ss - s) )
>  iommu_dom0_inclusive = val;
> +else if ( !strncmp(s, "reserved", ss - s) )
> +iommu_dom0_reserved = val;
>  else
>  rc = -EINVAL;
> 
> diff --git a/xen/drivers/passthrough/x86/iommu.c
> b/xen/drivers/passthrough/x86/iommu.c
> index bf6edf4c04..66c5cc28ed 100644
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
> 
> +#include 
>  #include 
> 
>  void iommu_update_ire_from_apic(
> @@ -134,15 +135,75 @@ void arch_iommu_domain_destroy(struct
> domain *d)
>  {
>  }
> 
> +static bool __hwdom_init iommu_map(const struct domain *d, unsigned
> long pfn,
> +   unsigned long max_pfn)

since the logic is limited to dom0, call "dom0_iommu_map" is clearer.

> +{
> +unsigned int i;
> +
> +/*
> + * Ignore any address below 1MB, that's already identity mapped by the
> + * domain builder for HVM.
> + */
> +if ( is_hvm_domain(d) && pfn < PFN_DOWN(MB(1)) )
> +

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

> -Original Message-
> From: Paul Durrant
> Sent: 02 August 2018 09:03
> To: 'Jan Beulich' 
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel  de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim (Xen.org) 
> Subject: RE: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make
> page table population preemptible"...
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 02 August 2018 08:20
> > To: Paul Durrant 
> > Cc: Julien Grall ; Andrew Cooper
> > ; Wei Liu ; George
> > Dunlap ; Ian Jackson
> ;
> > Stefano Stabellini ; xen-devel  > de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> > ; Tim (Xen.org) 
> > Subject: Re: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make
> > page table population preemptible"...
> >
> > >>> On 01.08.18 at 15:40,  wrote:
> > > ...to simplify the implementation and turn need_iommu back into a
> > boolean.
> > >
> > > As noted in [1] the tri-state nature of need_iommu after commit
> 3e06b989
> > is
> > > confusing, as is the implementation of pre-emption using relmem_list.
> > >
> > > This patch instead uses a simple count of pages already populated stored
> in
> > > the x86 variant of struct arch_iommu and skips over that number of
> pages
> > > if arch_iommu_populate_page_table() is re-invoked after pre-emption.
> >
> > Well, yes, I would have used that model in said commit if it was reliable,
> > but it isn't: What if the list of pages changed between two 
> > (re-)invocations?
> 
> Is that really going to happen? This is the result of a domctl, which is a 
> tools-
> only hypercall right?

Oh, I see what you mean... the guest could do something like a 
decrease_reservation... I was overlooking that setting up the iommu is 
happening while the guest is live. Would it be reasonable to domain_pause() for 
safety then?

  Paul

> 
> > Furthermore, with huge enough a guest even the skipping of the already
> > processed several million pages may exhaust the time acceptable between
> > preemption points.
> 
> Ok, I'll keep a pointer into the page list instead.
> 
>   Paul
> 
> >
> > Jan
> >


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

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

>>> On 02.08.18 at 10:04,  wrote:
>> From: Paul Durrant
>> Sent: 02 August 2018 09:03
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 02 August 2018 08:20
>> > >>> On 01.08.18 at 15:40,  wrote:
>> > > ...to simplify the implementation and turn need_iommu back into a
>> > boolean.
>> > >
>> > > As noted in [1] the tri-state nature of need_iommu after commit
>> 3e06b989
>> > is
>> > > confusing, as is the implementation of pre-emption using relmem_list.
>> > >
>> > > This patch instead uses a simple count of pages already populated stored
>> in
>> > > the x86 variant of struct arch_iommu and skips over that number of
>> pages
>> > > if arch_iommu_populate_page_table() is re-invoked after pre-emption.
>> >
>> > Well, yes, I would have used that model in said commit if it was reliable,
>> > but it isn't: What if the list of pages changed between two 
>> > (re-)invocations?
>> 
>> Is that really going to happen? This is the result of a domctl, which is a 
>> tools-
>> only hypercall right?
> 
> Oh, I see what you mean... the guest could do something like a 
> decrease_reservation... I was overlooking that setting up the iommu is 
> happening while the guest is live. Would it be reasonable to domain_pause() 
> for safety then?

I'm hesitant to see domains (or vcpus) paused other than when absolutely
necessary. If everyone else thinks this is a good idea here, I think I won't
object, but please don't forget that any pausing for perhaps an extended
period of time may cause the guest to misbehave subsequently.

Jan



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

Re: [Xen-devel] [PATCH v2 2/5] iommu: introduce dom0-iommu option

>>> On 02.08.18 at 09:46,  wrote:
>>  From: Roger Pau Monne [mailto:roger@citrix.com]
>> Sent: Wednesday, August 1, 2018 7:04 PM
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1150,12 +1150,18 @@ detection of systems known to misbehave
>> upon accesses to that port.
>> 
>>  > `dom0-passthrough`
>> 
>> +> **WARNING: This command line option is deprecated, and superseded
>> by
>> +> _dom0-iommu=none_ - using both options in combination is
>> undefined.**
>> +
> 
> in patch description you said 'supersede'... is it better to say that
> new dom0_iommu is favored if both options are specified than
> saying 'undefined'?

That would complicate handling (perhaps just slightly, but anyway),
since we'd have to maintain a second boolean. Without that the
order on the command line determines behavior. (And I see that in
the end you've figured that out.)

>> @@ -1198,6 +1204,32 @@ detection of systems known to misbehave upon
>> accesses to that port.
>> 
>>  >> Enable IOMMU debugging code (implies `verbose`).
>> 
>> +### dom0-iommu
>> +> `= List of [ none | strict | relaxed ]`
>> +
>> +> Sub-options are of boolean kind and can be prefixed with `no-` to effect
>> the
>> +> inverse meaning.
> 
> not important comment, but doesn't "no-none" sound weird? :-)

Only positive (true) values should be permitted for I think all of
these. I didn't look at the patch yes, so perhaps that's already
the case.

Jan



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

Re: [Xen-devel] [PATCH v4 07/32] libxl_qmp: Move struct sockaddr_un variable to qmp_open()

On Fri, Jul 27, 2018 at 03:05:49PM +0100, Anthony PERARD wrote:
> This variable is only used once, no need to keep it in the handler.
> 
> Also fix coding style (remove space after sizeof).
> And allow strncpy to use all the space in sun_path.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

> ---
> 
> Notes:
> v4:
> actually allow strncpy to use all the space in sun_path.
> 
>  tools/libxl/libxl_qmp.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 987bf0232e..1ffa17b632 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -105,7 +105,6 @@ typedef struct callback_id_pair {
>  } callback_id_pair;
>  
>  struct libxl__qmp_handler {
> -struct sockaddr_un addr;
>  int qmp_fd;
>  bool connected;
>  time_t timeout;
> @@ -431,6 +430,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char 
> *qmp_socket_path,
>  {
>  int ret = -1;
>  int i = 0;
> +struct sockaddr_un addr;

You could do:

struct sockaddr_un addr = { };

And get rid of the memset below.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH RFC] tools/kdd: avoid adversarial optimisation hazard

After some back and forth discussion on gcc-help, it is suggested this
is a bug in gcc and I'm asked to open a bug report.

Here is the bug report for reference:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827

Wei.

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

Re: [Xen-devel] [PATCH v4 08/32] libxl: Add libxl__prepare_sockaddr_un() helper

On Fri, Jul 27, 2018 at 03:05:50PM +0100, Anthony PERARD wrote:
> There is going to be a few more users that want to use UNIX socket, this
> helper is to prepare the `struct sockaddr_un` and check that the path
> isn't too long.
> 
> Also start to use it in libxl_qmp.c.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

LGTM, just one style nit.

> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 507ee56c7c..7907e20672 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -1234,6 +1234,20 @@ int libxl__random_bytes(libxl__gc *gc, uint8_t *buf, 
> size_t len)
>  return ret;
>  }
>  
> +int libxl__prepare_sockaddr_un(libxl__gc *gc,
> +   struct sockaddr_un *un, const char *path,
> +   const char *what) {

The brace should be on a newline according to the coding style.

Thanks, Roger.

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

[Xen-devel] [libvirt test] 125718: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 123814
 build-arm64   4 host-install(4)broken REGR. vs. 123814
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 123814
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  ce3c6ef6843f98d81be5423ece11fad79eaab920
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z   58 days
Failing since123840  2018-06-06 04:19:28 Z   57 days   44 attempts
Testing same since   125718  2018-08-01 04:18:52 Z1 days1 attempts


People who touched revisions under test:
Ales Musil 
  Andrea Bolognani 
  Anya Harter 
  Bjoern Walk 
  Bobo Du 
  Boris Fiuczynski 
  Brijesh Singh 
  Changkuo Shi 
  Chen Hanxiao 
  Christian Ehrhardt 
  Cole Robinson 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Erik Skultety 
  Fabiano Fidêncio 
  Filip Alac 
  Han Han 
  intrigeri 
  intrigeri 
  Jamie Strandboge 
  Jie Wang 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Katerina Koukiou 
  Laine Stump 
  Laszlo Ersek 
  Luyao Huang 
  Marc Hartmayer 
  Marc Hartmayer 
  Marcos Paulo de Souza 
  Martin Kletzander 
  Michal Privoznik 
  Michal Prívozník 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shi Lei 
  Shichangkuo 
  Simon Kobyda 
  Stefan Bader 
  Stefan Berger 
  Sukrit Bhatnagar 
  Tomáš Golembiovský 
  w00251574 
  Weilun Zhu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-ar

Re: [Xen-devel] [PATCH v4 11/32] libxl_dm: Add libxl__qemu_qmp_path()

On Fri, Jul 27, 2018 at 03:05:53PM +0100, Anthony PERARD wrote:
> ... which generate the path to a QMP socket that libxl uses.
^ generates
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

> ---
> 
> Notes:
> New in v4.
> 
>  tools/libxl/libxl_dm.c   | 9 +++--
>  tools/libxl/libxl_internal.h | 1 +
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index fdd7fa3ba4..5c28a0ced4 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -910,6 +910,11 @@ static char *qemu_disk_ide_drive_string(libxl__gc *gc, 
> const char *target_path,
>  return drive;
>  }
>  
> +const char *libxl__qemu_qmp_path(libxl__gc *gc, int domid)
> +{
> +return GCSPRINTF("%s/qmp-libxl-%d", libxl__run_dir_path(), domid);
> +}

You could place this as a static inline function in libxl_internal.h
directly IMO.

Roger.

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

[Xen-devel] failed to launch qemu when running de-privileged (xen 4.8)

2018-08-02 Thread James Dingwall

Hi,

I had a bit of a head scratcher while writing a patch for 4.8 which 
allows the qemu-dm process for a stubdom to be executed as an 
unprivileged user.  After a liberal sprinkling of log messages I found 
that my problem was related to the check of the return code from 
getpwnam_r.  In 4.11 the relevant code looks like this:


ret = NAME##_r(spec, resultbuf, buf, buf_size, &resultp);   \
if (ret == ERANGE) {\
buf_size += 128;\
continue;   \
}   \
if (ret != 0)   \
return ERROR_FAIL;  \
if (resultp != NULL) {  \
if (out) *out = resultp;\
return 1;   \
}   \
return 0;   \


if (ret != 0)   \
return ERROR_FAIL;  \


However checking the man page for getpwnam_r (and getpwuid_r now for 
4.11) it is not just 0 which can indicate an entry is not found:

   0 or ENOENT or ESRCH or EBADF or EPERM or ...
  The given name or uid was not found.
   EINTR  A signal was caught; see signal(7).
   EIOI/O error.
   EMFILE The per-process limit on the number of open file descriptors has 
been reached.
   ENFILE The system-wide limit on the total number of open files has been 
reached.
   ENOMEM Insufficient memory to allocate passwd structure.
   ERANGE Insufficient buffer space supplied.

In my case the domid specific qemu user was not present (just using 
xen-qemuuser-shared) and I was getting an ENOENT from getpwnam_r.
I'm sure there should be a more elegant way to write the check but
it solved my case.

+ret = getpwnam_r(username, &pwd, buf, buf_size, &user);
+if (ret == ERANGE) {
+buf_size += 128;
+continue;
+}
+if (ret == EINTR || ret == EIO || ret == EMFILE || ret == ENFILE || 
ret == ENOMEM)
+return ERROR_FAIL;
+if (user != NULL)
+return 1;
+return 0;

Thanks,
James

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

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 68bef3f0c7c71da2f065fd348efa79f04799d347
baseline version:
 ovmf d65b78f101b3f2845dc20b9556faf3f14904f3c5

Last test of basis   125734  2018-08-01 17:42:31 Z0 days
Testing same since   125738  2018-08-02 04:04:21 Z0 days1 attempts


People who touched revisions under test:
  Alexei Fedorov 
  AlexeiFedorov 
  Kinney, Michael D 
  Michael D Kinney 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   d65b78f101..68bef3f0c7  68bef3f0c7c71da2f065fd348efa79f04799d347 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 August 2018 09:19
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Tim (Xen.org) 
> Subject: RE: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make
> page table population preemptible"...
> 
> >>> On 02.08.18 at 10:04,  wrote:
> >> From: Paul Durrant
> >> Sent: 02 August 2018 09:03
> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
> >> > Sent: 02 August 2018 08:20
> >> > >>> On 01.08.18 at 15:40,  wrote:
> >> > > ...to simplify the implementation and turn need_iommu back into a
> >> > boolean.
> >> > >
> >> > > As noted in [1] the tri-state nature of need_iommu after commit
> >> 3e06b989
> >> > is
> >> > > confusing, as is the implementation of pre-emption using relmem_list.
> >> > >
> >> > > This patch instead uses a simple count of pages already populated
> stored
> >> in
> >> > > the x86 variant of struct arch_iommu and skips over that number of
> >> pages
> >> > > if arch_iommu_populate_page_table() is re-invoked after pre-
> emption.
> >> >
> >> > Well, yes, I would have used that model in said commit if it was 
> >> > reliable,
> >> > but it isn't: What if the list of pages changed between two (re-
> )invocations?
> >>
> >> Is that really going to happen? This is the result of a domctl, which is a
> tools-
> >> only hypercall right?
> >
> > Oh, I see what you mean... the guest could do something like a
> > decrease_reservation... I was overlooking that setting up the iommu is
> > happening while the guest is live. Would it be reasonable to
> domain_pause()
> > for safety then?
> 
> I'm hesitant to see domains (or vcpus) paused other than when absolutely
> necessary. If everyone else thinks this is a good idea here, I think I won't
> object, but please don't forget that any pausing for perhaps an extended
> period of time may cause the guest to misbehave subsequently.
> 

Yes, true, but I also wonder how safe it is to empty the page_list of a running 
guest. I guess it may be the best way but I think having a dedicate page_list 
in the iommu struct to host pages that have already been mapped and then 
transfer them back at the end would be cleaner and should allow need_iommu to 
stay boolean.

Also, given the expense of the operation to set up the mappings, I guess it may 
also be a good idea to leave them alone until domain destruction once the 
set-up has been done rather than removing them when the last device is 
de-assigned.

  Paul

> Jan
> 


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

Re: [Xen-devel] [PATCH v4 12/32] libxl: Design of an async API to issue QMP commands to QEMUç

On Fri, Jul 27, 2018 at 03:05:54PM +0100, Anthony PERARD wrote:
> All the functions will be implemented in later patches.
> 
> This patch includes the API that libxl can use to send QMP commands to
> QEMU.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_internal.h | 76 +++-
>  1 file changed, 74 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 5b71a23d23..c453ac10a5 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -202,6 +202,8 @@ typedef struct libxl__ao libxl__ao;
>  typedef struct libxl__aop_occurred libxl__aop_occurred;
>  typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus;
>  typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi;
> +typedef struct libxl__json_object libxl__json_object;
> +typedef struct libxl__carefd libxl__carefd;
>  
>  typedef struct libxl__domain_create_state libxl__domain_create_state;
>  typedef void libxl__domain_create_cb(struct libxl__egc *egc,
> @@ -357,6 +359,76 @@ struct libxl__ev_child {
>  LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
>  };
>  
> +/*
> + * QMP asynchronous calls
> + */

Place the title in the same comment block?

> +/*
> + * This facility allows a command to be sent to QEMU, and the response to be
> + * handed to a callback function.  Each libxl__ev_qmp handles zero or one

Do you really mean 'zero or one' or 'zero or more'?

> + * outstanding command.
> + *
> + * Commands can be chained, with a same connection. (e.g. "add-fd" will need 
> to
^ the
> + * be chained to the next command). A libxl__ev_qmp can be reused when the
 ^ after
> + * callback is been called in order to use the same connection.
   ^ has
> + *
> + * Only one connection at a time can be made to one QEMU, so avoid keeping a
   ^ to
> + * libxl__ev_qmp Connected for to long and call libxl__ev_qmp_dispose as soon
^ unneeded cap^ remove 'and'
> + * as it is not needed anymore.
> + *
> + * Possible states of a libxl__ev_qmp:
> + *  Undefined
> + *Might contain anything.
> + *  Idle
> + *Struct contents are defined enough to pass to any libxl__ev_qmp_*
> + *functions.
 ^ function
> + *The struct does not contain references to any allocated private 
> resources
> + *so can be thrown away.

I would add '... can be thrown away without any teardown.'

> + *  Active
> + *Currently waiting for the callback to be called.
> + *_dispose must be called to reclaim resources.
> + *  Connected
> + *Struct contain allocated ressources.
> + *Calling _send() with this same ev will use the same QMP connection.
> + *_dispose() must be called to reclaim resources.
> + *
> + * libxl__ev_qmp_init: Undefined/Idle -> Idle
> + *
> + * libxl__ev_qmp_send: Idle/Connected -> Active (on error: Idle)
> + *Sends a command to QEMU.
> + *callback will be called when a response is received or when an error
> + *as occured.
> + *
> + * libxl__ev_qmp_dispose: Connected/Active/Idle -> Idle
> + *
> + * callback: When called: Active -> Connected
> + *When called, ev is Connected and can be reused or disposed of.
> + *When an error occured, it is called with response == NULL and the error
 ^ If
> + *code in rc.
> + *The callback is only called once.
> + */
> +typedef struct libxl__ev_qmp libxl__ev_qmp;
> +typedef void libxl__ev_qmp_callback(libxl__egc *egc, libxl__ev_qmp *ev,
> +const libxl__json_object *response,
> +int rc);
> +
> +_hidden void libxl__ev_qmp_init(libxl__ev_qmp *ev);
> +_hidden int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
> +   const char *cmd, libxl__json_object *args);
> +_hidden void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev);
> +
> +struct libxl__ev_qmp {
> +/* caller should include this in their own struct */
> +/* caller must fill these in, and they must all remain valid */
   ^ no need for 'all'
> +uint32_t domid;

Strictly speaking domid is an uint16_t.

> +libxl__ev_qmp_callback *callback;
> +libxl__carefd *cfd; /* set to send a fd with the command, NULL otherwise 
> */
> +
> +/* remaining fields are private to libxl_ev_qmp_* */
> +

Extra newline?

> +int id;
> +};
> +

Thanks, Roger.

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

[Xen-devel] [PATCH] tools: fix python shebangs to use /usr/bin/env

2018-08-02 Thread Roger Pau Monne

The path to the python binary can be different from /usr/bin/python
depending on the distro/OS.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Christian Lindig 
Cc: David Scott 
---
 tools/include/xen-foreign/mkchecker.py   | 2 +-
 tools/include/xen-foreign/mkheader.py| 2 +-
 tools/libxl/gentest.py   | 2 +-
 tools/libxl/gentypes.py  | 2 +-
 tools/misc/xen-ringwatch | 2 +-
 tools/misc/xencov_split  | 2 +-
 tools/ocaml/libs/xentoollog/genlevels.py | 2 +-
 tools/ocaml/libs/xl/genwrap.py   | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/include/xen-foreign/mkchecker.py 
b/tools/include/xen-foreign/mkchecker.py
index fdad869a91..3f1debf3af 100644
--- a/tools/include/xen-foreign/mkchecker.py
+++ b/tools/include/xen-foreign/mkchecker.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import sys;
 from structs import structs, compat_arches;
diff --git a/tools/include/xen-foreign/mkheader.py 
b/tools/include/xen-foreign/mkheader.py
index 97e0c7a984..812f50ed4e 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import sys, re;
 from structs import unions, structs, defines;
diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 989959fc68..fbf577d4b5 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import os
 import sys
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 88e5c5f30e..a36abfb0aa 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import sys
 import re
diff --git a/tools/misc/xen-ringwatch b/tools/misc/xen-ringwatch
index e6f5361231..df7db5c312 100644
--- a/tools/misc/xen-ringwatch
+++ b/tools/misc/xen-ringwatch
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 #
 # Copyright (C) 2011 Citrix Systems, Inc.
 #
diff --git a/tools/misc/xencov_split b/tools/misc/xencov_split
index 1f20518b86..5771f6cfc2 100755
--- a/tools/misc/xencov_split
+++ b/tools/misc/xencov_split
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import sys, os, os.path as path, struct, errno
 from optparse import OptionParser
diff --git a/tools/ocaml/libs/xentoollog/genlevels.py 
b/tools/ocaml/libs/xentoollog/genlevels.py
index 8c233c59b1..9dd3048a46 100755
--- a/tools/ocaml/libs/xentoollog/genlevels.py
+++ b/tools/ocaml/libs/xentoollog/genlevels.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import sys
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 9a65d7334d..75ed4b400d 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 
 import sys,os
 
-- 
2.18.0


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

Re: [Xen-devel] [PATCH] tools: fix python shebangs to use /usr/bin/env

2018-08-02 Thread Christian Lindig



> On 2 Aug 2018, at 10:05, Roger Pau Monne  wrote:
> 
> The path to the python binary can be different from /usr/bin/python
> depending on the distro/OS.
> 
> Signed-off-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH v4 13/32] libxl_qmp: Connect to QMP socket

On Fri, Jul 27, 2018 at 03:05:55PM +0100, Anthony PERARD wrote:
> This is a first patch to implement libxl__ev_qmp, it only connect to the
^ connects
> QMP socket of QEMU and register a fd callback that does nothing.
 ^ registers
> 
> Callback functions will be implemented in following patches.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_internal.h | 11 +
>  tools/libxl/libxl_qmp.c  | 96 
>  2 files changed, 107 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index c453ac10a5..90ac48a659 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -417,6 +417,14 @@ _hidden int libxl__ev_qmp_send(libxl__gc *gc, 
> libxl__ev_qmp *ev,
> const char *cmd, libxl__json_object *args);
>  _hidden void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev);
>  
> +typedef enum {
> +qmp_state_disconnected = 1,
> +qmp_state_connecting,
> +qmp_state_greeting,
> +qmp_state_capability_negociation,
> +qmp_state_connected,
> +} libxl__qmp_state;
> +

I think this should be declared in libxl_types_internal.idl?

And (maybe) a description of each state would be helpful for future
reference?

>  struct libxl__ev_qmp {
>  /* caller should include this in their own struct */
>  /* caller must fill these in, and they must all remain valid */
> @@ -427,6 +435,9 @@ struct libxl__ev_qmp {
>  /* remaining fields are private to libxl_ev_qmp_* */
>  
>  int id;
> +libxl__carefd *qmp_cfd;
> +libxl__ev_fd qmp_efd;
> +libxl__qmp_state qmp_state;
>  };
>  
>  
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index c5e05e5679..96a347dd3b 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1276,6 +1276,102 @@ int libxl__qmp_initializations(libxl__gc *gc, 
> uint32_t domid,
>  return ret;
>  }
>  
> +/*  Implementation of libxl__ev_qmp  */
> +
> +static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
> +   int fd, short events, short revents)
> +{
> +}
> +
> +static int qmp_ev_connect(libxl__gc *gc, libxl__ev_qmp *ev)
> +{
> +int rc, r;
> +struct sockaddr_un un;
> +const char *qmp_socket_path;
> +
> +if (ev->qmp_state != qmp_state_disconnected)
> +return 0;
> +
> +qmp_socket_path = libxl__qemu_qmp_path(gc, ev->domid);
> +
> +LOGD(DEBUG, ev->domid, "Connecting to %s", qmp_socket_path);
> +
> +libxl__carefd_begin();
> +ev->qmp_cfd = libxl__carefd_opened(CTX, socket(AF_UNIX, SOCK_STREAM, 0));
> +if (!ev->qmp_cfd) {
> +LOGED(ERROR, ev->domid, "socket() failed");
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +rc = libxl_fd_set_nonblock(CTX, libxl__carefd_fd(ev->qmp_cfd), 1);
> +if (rc)
> +goto out;
> +
> +rc = libxl__prepare_sockaddr_un(gc, &un, qmp_socket_path, "QMP socket");
> +if (rc)
> +goto out;
> +
> +r = connect(libxl__carefd_fd(ev->qmp_cfd),
> +(struct sockaddr *) &un, sizeof(un));
> +if (r) {
> +LOGED(ERROR, ev->domid, "Failed to connect to QMP socket %s",
> +  qmp_socket_path);
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +rc = libxl__ev_fd_register(gc, &ev->qmp_efd, qmp_ev_fd_callback,
> +   libxl__carefd_fd(ev->qmp_cfd), POLLIN);
> +if (rc)
> +goto out;
> +
> +ev->qmp_state = qmp_state_connecting;
> +return 0;
> +
> +out:
> +libxl__carefd_close(ev->qmp_cfd);
> +ev->qmp_cfd = NULL;
> +return rc;
> +}
> +
> +

Double newline.

> +/*
> + * libxl__ev_qmp_*
> + */
> +
> +void libxl__ev_qmp_init(libxl__ev_qmp *ev)
> +{
> +ev->id = -1;
> +
> +ev->qmp_cfd = NULL;
> +libxl__ev_fd_init(&ev->qmp_efd);
> +ev->qmp_state = qmp_state_disconnected;
> +}
> +
> +int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
> +   const char *cmd, libxl__json_object *args)
> +{
> +int rc;
> +
> +LOGD(DEBUG, ev->domid, " ev %p, cmd '%s'", ev, cmd);
> +
> +/* Connect to QEMU if not already connected */
> +rc = qmp_ev_connect(gc, ev);
> +
> +return rc;

You can get rid of rc and just use:

return qmp_ev_connect(gc, ev);

> +}
> +
> +void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev)
> +{
> +LOGD(DEBUG, ev->domid, " ev %p", ev);
> +
> +libxl__ev_fd_deregister(gc, &ev->qmp_efd);
> +libxl__carefd_close(ev->qmp_cfd);
> +ev->qmp_cfd = NULL;

No need to set qmp_cfd to NULL if you call _init afterwards.

> +
> +libxl__ev_qmp_init(ev);

Thanks, Roger.

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

[Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization


Hi,

Sorry for the late posting. The notes were taken by Stefano Stabellini. 
Thank you.


This has some clarifications requested from EPAM regarding PowerVR.

The existing graphics solutions on Xen today are:
   - PV DRM:
* Supports multiple displays per VM
* Based on Grant-tables.
* Improvement of Xen FB which is based on foreign mapping

   - Intel GVT: https://01.org/igvt-g
* Based on IOREQ server infrastructure
* Performance is 70% of direct assigned hardware

   - NVIDIA:
* Much more virtualizable
* Provide mappable chunk of PCI BARs.
* Userspace component emulates PCI config space

Current effort for graphic virtualization on Arm:
   - Samsung: They have a PV OpenGL solution. This seems to be fast.
   - EPAM:
* PV OpenGL was dismissed because of performance concern
* PV DRM for sharing display
* PowerVR native virtualization (see below)

PoverVR virtualization:

Recent PoverVR hardware provided some virtualization support. The
solution is implemented in the firmware. A kernel module is used to talk
to the firmware via shared memory. The toolstack only have to setup
memory context for each VM.

   ** Recent PoverVR HW has some virtualization support
   ** Kernel module

It was not clear whether an extra pair of frontend/backend was required 
along with the PowerVR driver.


@Action: EPAM, could you clarify it?

Potential solution for upstream:
   - PV OpenGL
   - vGPU solution outside of the hypervisor (see below)

vGPU solution outside of the hypervisor:

A unikernel (or Dom0) based environment could be provided to run
proprietary software.

The proprietary software would use IOREQ server infrastructure to
emulate guest memory region used by the GPU and do the scheduling
decisions.


--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 14/32] libxl_qmp: Implement fd callback and read data

On Fri, Jul 27, 2018 at 03:05:56PM +0100, Anthony PERARD wrote:
> First step into taking care of the input from QEMU's QMP socket. For
> now, we read data and store them in a buffer.
> 
> Parsing of the data will be done in the following patches.
> 
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
> v4:
> remove use of a linked list of receive buffer, and use realloc 
> instead.
> 
>  tools/libxl/libxl_internal.h |   9 
>  tools/libxl/libxl_qmp.c  | 101 +++
>  2 files changed, 110 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 90ac48a659..8c3625a243 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -438,6 +438,15 @@ struct libxl__ev_qmp {
>  libxl__carefd *qmp_cfd;
>  libxl__ev_fd qmp_efd;
>  libxl__qmp_state qmp_state;
> +
> +/* receive buffer, with:
> + * buf_size: current allocated size,
> + * buf_used: actual data in the buffer,
> + * buf_consumed: data already parsed.  */
> +char *rx_buf;
> +size_t buf_size;
> +size_t buf_used;
> +size_t buf_consumed;
>  };
>  
>  
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 96a347dd3b..b0554df843 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -75,6 +75,12 @@
>  #  define DEBUG_REPORT_RECEIVED(dom, buf, len) ((void)0)
>  #endif
>  
> +#ifdef DEBUG_QMP_CLIENT
> +#  define LOG_QMP(f, ...) LOGD(DEBUG, ev->domid, f, ##__VA_ARGS__)
> +#else
> +#  define LOG_QMP(f, ...)
> +#endif
> +
>  /*
>   * QMP types & constant
>   */
> @@ -1278,9 +1284,99 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
> domid,
>  
>  /*  Implementation of libxl__ev_qmp  */
>  
> +/*
> + * QMP FD callbacks
> + */
> +
> +static int qmp_ev_callback_readable(libxl__egc *egc, libxl__ev_qmp *ev, int 
> fd)
> +{
> +EGC_GC;
> +ssize_t r;
> +
> +if (!ev->rx_buf) {
> +ev->rx_buf = libxl__malloc(NOGC, QMP_RECEIVE_BUFFER_SIZE);
> +ev->buf_size = QMP_RECEIVE_BUFFER_SIZE;
> +ev->buf_used = 0;
> +ev->buf_consumed = 0;
> +}
> +
> +/* Check if last buffer still have space, or increase size */
> +/* The -1 is because there is always space for a NUL character */
> +if (ev->buf_used == ev->buf_size - 1) {
> +ev->buf_size += QMP_RECEIVE_BUFFER_SIZE;
> +ev->rx_buf = libxl__realloc(NOGC, ev->rx_buf, ev->buf_size);
> +}
> +
> +for (;;) {
> +/* The -1 is because there is always space for a NUL character */
> +r = read(fd, ev->rx_buf + ev->buf_used,
> + ev->buf_size - ev->buf_used - 1);
> +if (r < 0) {
> +if (errno == EINTR) continue;
> +assert(errno);
> +if (errno == EWOULDBLOCK) {
> +return 0;
> +}
> +LOGED(ERROR, ev->domid, "error reading QMP socket");
> +return ERROR_FAIL;

I think it would be clearer to use:

assert(errno);
switch (errno) {
case EINTR:
continue;
case EWOULDBLOCK
return 0;
default:
LOGED(...)

> +}
> +break;
> +}
> +
> +if (r == 0) {
> +LOGD(ERROR, ev->domid, "No data read on QMP socket");
> +return 0;
> +}
> +
> +LOG_QMP("received %ldB: '%.*s'", r, (int)r, ev->rx_buf + ev->buf_used);
> +
> +ev->buf_used += r;

Hm, don't you need to do this inside of a loop together with the
realloc, in case the data on the fd is bigger than the current space
on the buffer, and you need to keep growing it until you hit
EWOULDBLOCK?

I think with the current approach you can leave data pending in the fd
if the buffer happens to be smaller than the pending data in the fd?

I think the loop should be something like:

for (;;) {
1. Check if there's space left in the buffer.
2. Try to read from the fd.
3. Parse error, exit loop if errno == EWOULDBLOCK.
4. ev->buf_used += r;
5. Restart loop.
}

> +assert(ev->buf_used < ev->buf_size);
> +
> +return 0;
> +}
> +
> +static void qmp_ev_callback_error(libxl__egc *egc, libxl__ev_qmp *ev)
> +{
> +EGC_GC;
> +
> +LOGD(ERROR, ev->domid, "Error happend with the QMP connection to QEMU");
> +
> +/* On error, deallocate all private ressources */
> +libxl__ev_qmp_dispose(gc, ev);
> +}
> +
>  static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
> int fd, short events, short revents)
>  {
> +EGC_GC;
> +int rc;
> +
> +libxl__ev_qmp *ev = CONTAINER_OF(ev_fd, *ev, qmp_efd);
> +
> +if (revents & (POLLHUP)) {
> +LOGD(DEBUG, ev->domid, "received POLLHUP from QMP socket");
> +qmp_ev_callback_error(egc, ev);
> +return;
> +}
> +if (revents & ~(POLLIN|POLLOUT)) {
> +LOGD(ERROR, ev->domid,
> + "unexpected poll event 0x%x on QMP socket (expected POLLIN "
> + "and/or POLLOUT)",
> +

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

>>> On 02.08.18 at 10:49,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 02 August 2018 09:19
>> To: Paul Durrant 
>> Cc: Julien Grall ; Andrew Cooper
>> ; George Dunlap
>> ; Ian Jackson ; Wei Liu
>> ; Stefano Stabellini ; xen-
>> devel ; Konrad Rzeszutek Wilk
>> ; Tim (Xen.org) 
>> Subject: RE: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make
>> page table population preemptible"...
>> 
>> >>> On 02.08.18 at 10:04,  wrote:
>> >> From: Paul Durrant
>> >> Sent: 02 August 2018 09:03
>> >> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> > Sent: 02 August 2018 08:20
>> >> > >>> On 01.08.18 at 15:40,  wrote:
>> >> > > ...to simplify the implementation and turn need_iommu back into a
>> >> > boolean.
>> >> > >
>> >> > > As noted in [1] the tri-state nature of need_iommu after commit
>> >> 3e06b989
>> >> > is
>> >> > > confusing, as is the implementation of pre-emption using relmem_list.
>> >> > >
>> >> > > This patch instead uses a simple count of pages already populated
>> stored
>> >> in
>> >> > > the x86 variant of struct arch_iommu and skips over that number of
>> >> pages
>> >> > > if arch_iommu_populate_page_table() is re-invoked after pre-
>> emption.
>> >> >
>> >> > Well, yes, I would have used that model in said commit if it was 
>> >> > reliable,
>> >> > but it isn't: What if the list of pages changed between two (re-
>> )invocations?
>> >>
>> >> Is that really going to happen? This is the result of a domctl, which is a
>> tools-
>> >> only hypercall right?
>> >
>> > Oh, I see what you mean... the guest could do something like a
>> > decrease_reservation... I was overlooking that setting up the iommu is
>> > happening while the guest is live. Would it be reasonable to
>> domain_pause()
>> > for safety then?
>> 
>> I'm hesitant to see domains (or vcpus) paused other than when absolutely
>> necessary. If everyone else thinks this is a good idea here, I think I won't
>> object, but please don't forget that any pausing for perhaps an extended
>> period of time may cause the guest to misbehave subsequently.
>> 
> 
> Yes, true, but I also wonder how safe it is to empty the page_list of a 
> running guest. I guess it may be the best way but I think having a dedicate 
> page_list in the iommu struct to host pages that have already been mapped and 
> then transfer them back at the end would be cleaner and should allow 
> need_iommu to stay boolean.

The issue is with the case of the guest trying to free a page - see
arch_free_heap_page(): The way page lists work when link fields
are 32-bit PDXes, all lists a page may possibly be on need to be
inspected, in case the page is at the head of that list. Introducing a
3rd list to take into consideration seems undesirable to me (and
again I did consider that option back when writing things the way
they are now).

Jan



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

Re: [Xen-devel] [PATCH v4 15/32] libxl_json: Enable yajl_allow_trailing_garbage

On Fri, Jul 27, 2018 at 03:05:57PM +0100, Anthony PERARD wrote:
> This allow to parse a string that is not NUL-terminated. With that
   ^ allows
> options disabled, YAJL v2 would look ahead on completion to find out if
  ^ option
> there is more to parse.
> 
> YAJL v1 doesn't have this behavior.
> 
> Any function function that allocate a yajl_handle via this function
  ^ duplicated   ^ allocates
> either parse a NUL-terminated string, or do provide proper length. So
> change the default and allow garbage (like a different JSON document)
> after the end of the data to parse.
> 
> This is importand for the QMP client, as there could be more than one
  ^ important
> message to parse, and YAJL would consider the next message to be
> garbage and throw an error.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

[Xen-devel] [xen-4.9-testing test] 125710: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 test-amd64-i386-pair broken
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 124328
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 124328
 build-arm64   4 host-install(4)broken REGR. vs. 124328
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 124328
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125686 REGR. vs. 
124248

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pair  5 host-install/dst_host(5) broken pass in 125686
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail 
pass in 125686
 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail pass in 125686
 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail pass in 125686

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 124328
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 125686 blocked in 
124328
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 125686 
like 124328
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop  fail in 125686 like 124328
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 125686 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 125686 never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 125686 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 125686 never 
pass
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 125686 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 125686 never 
pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 125686 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 125686 never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 124248
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
124248
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 124328
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124328
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never

Re: [Xen-devel] [PATCH v4 16/32] libxl_json: libxl__json_object_to_json

On Fri, Jul 27, 2018 at 03:05:58PM +0100, Anthony PERARD wrote:
> Allow to generate a JSON string from a libxl__json_object,
> usefull for debugging.
  ^ useful
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Jackson 

Reviewed-by: Roger Pau Monné 

> ---
>  tools/libxl/libxl_internal.h |  3 +++
>  tools/libxl/libxl_json.c | 36 
>  2 files changed, 39 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 8c3625a243..7f200e7a46 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -2129,6 +2129,9 @@ _hidden void libxl__json_object_free(libxl__gc *gc_opt,
>  
>  _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char 
> *s);
>  
> +_hidden char *libxl__json_object_to_json(libxl__gc *gc,
> + const libxl__json_object *args);
> +
>/* Based on /local/domain/$domid/dm-version xenstore key
> * default is qemu xen traditional */
>  _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t 
> domid);
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index b7f9077f0d..16cdd5bda3 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -1017,6 +1017,42 @@ out:
>  return ret;
>  }
>  
> +char *libxl__json_object_to_json(libxl__gc *gc,
> + const libxl__json_object *args)
> +{
> +const unsigned char *buf;
> +libxl_yajl_length len;
> +yajl_gen_status s;
> +yajl_gen hand;
> +char *ret = NULL;
> +int rc;
> +
> +if (!args)
> +return NULL;
> +
> +hand = libxl_yajl_gen_alloc(NULL);
> +

I would remove this newline.

> +if (!hand) {
> +return NULL;
> +}
> +
> +rc = libxl__json_object_to_yajl_gen(gc, hand, args);
> +if (rc)
> +goto out;
> +
> +s = yajl_gen_get_buf(hand, &buf, &len);
> +

And this one.

> +if (s) {
> +goto out;
> +}

Thanks, Roger.

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

[Xen-devel] [xen-unstable test] 125716: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 125691
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 125691
 build-arm64   4 host-install(4)broken REGR. vs. 125691
 test-armhf-armhf-xl-credit2   6 xen-install  fail REGR. vs. 125691

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

version targeted for testing:
 xen  6aaa9fb308171ec58ddf4cf058ad5341f81a65cf
baseline version:
 xen  1f7574763cbb2c85825b8cc4d81f386e767a476f

Last test of basis   125691  2018-07-30 21:37:12 Z2 days
Testing same since   125716  2018-08-01 03:36:29 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel Kiper 
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Norbert Manthey 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-

Re: [Xen-devel] [PATCH] tools: fix python shebangs to use /usr/bin/env

On Thu, Aug 02, 2018 at 11:05:27AM +0200, Roger Pau Monne wrote:
> The path to the python binary can be different from /usr/bin/python
> depending on the distro/OS.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] docs/xl: Clarify documentation for mem-max and mem-set

2018-08-02 Thread George Dunlap

On 08/01/2018 05:16 PM, Lars Kurth wrote:
> 
> 
> On 01/08/2018, 16:41, "George Dunlap"  wrote:
> 
> mem-set is the primary command that users will need to use and
> understand.  Move it first, and clarify the wording; also specify that
> you can't set the target higher than maxmem from the domain config.
> 
> mem-max is actually a pretty useless command at the moment.  Clarify
> that users are not expected to use it; and document all of its quirky
> behavior.
> 
> Signed-off-by: George Dunlap 
> ---
> I'm actully somewhat tempted to take out the entry for mem-max
> entirely -- it's not at all clear to me what anyone would use it for,
> and it's only likely to confuse people.
> 
> Should it be deprecated, if it isn't useful?
> 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Konrad Wilk 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Lars Kurth 
> ---
>  docs/man/xl.pod.1.in | 72 ++--
>  1 file changed, 50 insertions(+), 22 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
> index b74764dcd3..1d3dabf185 100644
> --- a/docs/man/xl.pod.1.in
> +++ b/docs/man/xl.pod.1.in
> @@ -393,40 +393,68 @@ less utilized than a high CPU workload.  Consider 
> yourself warned.
>  
>  =back
>  
> -=item B I I
> +=item B I I
>  
> -Specify the maximum amount of memory the domain is able to use, 
> appending 't'
> -for terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for kilobytes 
> and 'b'
> -for bytes.
> +Set the target for the domain's balloon driver.  Append 't' for
> 
> I would say Use instead of Append: if you are not a native speaker you could
> be misled that the command appends memory.

I'm afraid 'use' doesn't tell me what to do -- `set-max A t`? `set-max A
2048 t`?  `set-max A t2048`?

What about making a paragraph break and changing it to:

"The default unit is kiB.  Add 't' to specify TiB, 'g' for GiB, 'm' for
MiB, and 'b' for bytes (e.g., 2048m)."

Alternate we could say `I[]`, but that seems to be getting a
little clunky.

> +terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for kilobytes
> +and 'b' for bytes.
>  
> -The mem-max value may not correspond to the actual memory used in the
> -domain, as it may balloon down its memory to give more back to the OS.
> +This must be less than the initial B parameter in the domain's
> +configuration.
> 
> What happens if it is bigger? Will you get an error, or will the system 
> likely 
> crash?

libxl will return an error.  It's never OK for a command for which we
have a precise limit to crash the system.  (NB the WARNING at the bottom
of this section, about not having a clear lower limit.)

> Reviewed-by: lars.ku...@citrix.com

Thanks

 -George

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

Re: [Xen-devel] [xen-4.9-testing test] 125710: regressions - trouble: blocked/broken/fail/pass

>>> On 02.08.18 at 12:05,  wrote:
> flight 125710 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/125710/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
> vs. 124328

This one also failed in 125686. In both cases there is

error: Timed out during operation: cannot acquire state change lock

in the test log, which I have no idea what it means.

Jan



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

Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

> -Original Message-
> From: Roger Pau Monne
> Sent: 01 August 2018 17:15
> To: Paul Durrant 
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julien Grall ; Jan Beulich
> 
> Subject: Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989
> "IOMMU: make page table population preemptible"...
> 
> On Wed, Aug 01, 2018 at 02:40:14PM +0100, Paul Durrant wrote:
> > ...to simplify the implementation and turn need_iommu back into a
> boolean.
> >
> > As noted in [1] the tri-state nature of need_iommu after commit 3e06b989
> is
> > confusing, as is the implementation of pre-emption using relmem_list.
> >
> > This patch instead uses a simple count of pages already populated stored in
> > the x86 variant of struct arch_iommu and skips over that number of pages
> > if arch_iommu_populate_page_table() is re-invoked after pre-emption.
> 
> Urg, all this is quite ugly. It would be quite better if the need for
> an IOMMU was decided before populating the p2m (ie: at domain_create
> time by passing an extra XEN_DOMCTL_CDF_iommu or some such), so that
> the normal addition of RAM would also populate the IOMMU page tables
> if not shared.

Given the problems that Jan has highlighted with using a skip count and 
essentially being forced to mess with the domain's page list, I think your 
suggestion is best. Then we can entirely bin arch_iommu_populate_page_table(). 
That is a bigger piece of work though so in the interest of no blocking the 
rest of this series I'll drop this patch and replace it with a simpler patch 
that's just sufficient to make need_iommu boolean again.

  Paul

> 
> > [1] https://lists.xenproject.org/archives/html/xen-devel/2018-
> 07/msg01870.html
> >
> > Signed-off-by: Paul Durrant 
> 
> Reviewed-by: Roger Pau Monné 
> 
> Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 17/32] libxl_qmp: Parse JSON input from QMP

On Fri, Jul 27, 2018 at 03:05:59PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
> v4:
> simplification of the patch due to use of a single allocated space 
> for the
> receive buffer.
> 
>  tools/libxl/libxl_qmp.c | 54 +
>  1 file changed, 54 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index b0554df843..665b6f5d05 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1292,6 +1292,7 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
> libxl__ev_qmp *ev, int fd)
>  {
>  EGC_GC;
>  ssize_t r;
> +char *end = NULL;
>  
>  if (!ev->rx_buf) {
>  ev->rx_buf = libxl__malloc(NOGC, QMP_RECEIVE_BUFFER_SIZE);
> @@ -1333,6 +1334,59 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
> libxl__ev_qmp *ev, int fd)
>  ev->buf_used += r;
>  assert(ev->buf_used < ev->buf_size);
>  
> +/* workaround strstr limitation */
> +ev->rx_buf[ev->buf_used] = '\0';

Why not use strnstr to limit the size of the rx_buf that's searched? I
think that would allow you to get rid of the '-1' that you have to
take into account in several places?

> +
> +/*
> + * Search for the end of a QMP message: "\r\n" in the newly received
> + * bytes + the last byte on the previous read() if any
> + *
> + * end: This will point to the byte right after \r\n
> + */
> +end = strstr(ev->rx_buf + ev->buf_used - r
> + + (ev->buf_used - r == 0 ? 0 : -1),
> + "\r\n");
> +if (end)
> +end += 2;
> +
> +while (end) {
> +libxl__json_object *o;
> +size_t len;
> +char *s;
> +
> +/* Start parsing from s */
> +s = ev->rx_buf + ev->buf_consumed;
> +/* Findout how much can be parsed */
> +len = end - s;

You can init both s and len above when defining them.

> +
> +LOG_QMP("parsing %luB: '%.*s'", len, (int)len, s);
> +
> +/* Replace \n by \0 so that libxl__json_parse can use strlen */
> +s[len - 1] = '\0';
> +o = libxl__json_parse(gc, s); //, len);

Doesn't look like the above line will compile.

> +
> +if (!o) {
> +LOGD(ERROR, ev->domid, "Parse error");
> +return ERROR_FAIL;
> +}
> +
> +ev->buf_consumed += len;
> +
> +if (ev->buf_consumed >= ev->buf_used) {

I'm not sure I see how the above check can ever be true, you search
the buffer up to buf_used, so 'end' can never be past buf_used?

> +free(ev->rx_buf);
> +ev->rx_buf = NULL;
> +}
> +
> +/* check if there is another message received at the same time */
> +if (ev->rx_buf) {
> +end = strstr(ev->rx_buf + ev->buf_consumed, "\r\n");
> +if (end)
> +end += 2;
> +} else
> +end = NULL;
> +
> +LOG_QMP("JSON object received: %s", libxl__json_object_to_json(gc, 
> o));
> +}

Newline.

>  return 0;

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 18/32] libxl_qmp: Separate QMP message generation from qmp_send_prepare

On Fri, Jul 27, 2018 at 03:06:00PM +0100, Anthony PERARD wrote:
> To be able to re-use qmp_prepare_qmp_cmd with libxl__ev_qmp.
> 
> Also, add the QMP end of command '\r\n' into the generated string.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_qmp.c | 62 +
>  1 file changed, 44 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 665b6f5d05..38a4395266 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -578,17 +578,17 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
> *qmp)
>  return rc;
>  }
>  
> -static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
> -  const char *cmd, libxl__json_object *args,
> -  qmp_callback_t callback, void *opaque,
> -  qmp_request_context *context)
> -{
> -const unsigned char *buf = NULL;
> -char *ret = NULL;
> -libxl_yajl_length len = 0;
> +static char *qmp_prepare_qmp_cmd(libxl__gc *gc,

Is it really needed to have qmp twice in the function name?
qmp_prepare_cmd LGTM.

> + const char *cmd,
> + const libxl__json_object *args,
> + int id,
> + size_t *len_r)
> +{
> +const unsigned char *buf;

While there I would drop the unsigned...

> +libxl_yajl_length len;
>  yajl_gen_status s;
>  yajl_gen hand;
> -callback_id_pair *elm = NULL;
> +char *ret = NULL;
>  
>  hand = libxl_yajl_gen_alloc(NULL);
>  
> @@ -600,7 +600,7 @@ static char *qmp_send_prepare(libxl__gc *gc, 
> libxl__qmp_handler *qmp,
>  libxl__yajl_gen_asciiz(hand, "execute");
>  libxl__yajl_gen_asciiz(hand, cmd);
>  libxl__yajl_gen_asciiz(hand, "id");
> -yajl_gen_integer(hand, ++qmp->last_id_used);
> +yajl_gen_integer(hand, id);
>  if (args) {
>  libxl__yajl_gen_asciiz(hand, "arguments");
>  libxl__json_object_to_yajl_gen(gc, hand, args);
> @@ -610,6 +610,36 @@ static char *qmp_send_prepare(libxl__gc *gc, 
> libxl__qmp_handler *qmp,
>  s = yajl_gen_get_buf(hand, &buf, &len);
>  
>  if (s) {
> +goto out;
> +}
> +
> +ret = libxl__malloc(NOGC, len + 3);
> +strncpy(ret, (const char *)buf, len + 3);

... so that you can drop the cast from here.

> +strncpy(ret + len, "\r\n", 3);
> +len += 2;
> +
> +if (len_r)
> +*len_r = len;
> +
> +out:
> +yajl_gen_free(hand);
> +return ret;
> +}
> +
> +static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
> +  const char *cmd, libxl__json_object *args,
> +  qmp_callback_t callback, void *opaque,
> +  qmp_request_context *context,
> +  size_t *len_r)
> +{
> +char *buf;
> +callback_id_pair *elm;
> +
> +buf = qmp_prepare_qmp_cmd(gc,
> +  cmd, args, ++qmp->last_id_used,
> +  NULL);

Indentation is very weird here. AFAICT it can fit in a single line?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 19/32] libxl_qmp: Prepare the command to be sent

On Fri, Jul 27, 2018 at 03:06:01PM +0100, Anthony PERARD wrote:
> The actual sent will be done in a separate patch.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_internal.h |  4 
>  tools/libxl/libxl_qmp.c  | 37 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7f200e7a46..110b951bbe 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -438,6 +438,7 @@ struct libxl__ev_qmp {
>  libxl__carefd *qmp_cfd;
>  libxl__ev_fd qmp_efd;
>  libxl__qmp_state qmp_state;
> +unsigned int last_id_used;

Now there are two last_id_used fields in different structures?
Shouldn't the previous one be removed when you introduce this new one?

>  
>  /* receive buffer, with:
>   * buf_size: current allocated size,
> @@ -447,6 +448,9 @@ struct libxl__ev_qmp {
>  size_t buf_size;
>  size_t buf_used;
>  size_t buf_consumed;
> +
> +char *tx_buf;
> +size_t tx_buf_len;
>  };
>  
>  
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 38a4395266..2792f35912 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1310,6 +1310,25 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
> domid,
>  
>  /*  Implementation of libxl__ev_qmp  */
>  
> +static int qmp_ev_prepare_cmd(libxl__gc *gc,
> +  libxl__ev_qmp *ev,
> +  const char *cmd,
> +  const libxl__json_object *args)
> +{
> +char *buf = NULL;
> +size_t len;
> +
> +buf = qmp_prepare_qmp_cmd(gc, cmd, args, ++ev->last_id_used, &len);
> +if (!buf)
> +return ERROR_FAIL;
> +
> +ev->id = ev->last_id_used;
> +ev->tx_buf = buf;
> +ev->tx_buf_len = len;
> +
> +return 0;
> +}
> +
>  /*
>   * QMP FD callbacks
>   */
> @@ -1424,6 +1443,9 @@ static void qmp_ev_callback_error(libxl__egc *egc, 
> libxl__ev_qmp *ev)
>  
>  /* On error, deallocate all private ressources */
>  libxl__ev_qmp_dispose(gc, ev);
> +
> +ev->id = -1;
> +ev->callback(egc, ev, NULL, ERROR_FAIL);
>  }
>  
>  static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
> @@ -1522,8 +1544,10 @@ void libxl__ev_qmp_init(libxl__ev_qmp *ev)
>  ev->qmp_cfd = NULL;
>  libxl__ev_fd_init(&ev->qmp_efd);
>  ev->qmp_state = qmp_state_disconnected;
> +ev->last_id_used = 0;
>  
>  ev->rx_buf = NULL;
> +ev->tx_buf = NULL;

ev->tx_buf_len = 0;

I think.

>  }
>  
>  int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
> @@ -1535,7 +1559,17 @@ int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp 
> *ev,
>  
>  /* Connect to QEMU if not already connected */
>  rc = qmp_ev_connect(gc, ev);
> +if (rc)
> +goto out;
> +
> +rc = qmp_ev_prepare_cmd(gc, ev, cmd, args);
> +if (rc)
> +goto out;
> +
>  

Double newline?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 20/32] libxl_qmp: Handle write to QMP socket

On Fri, Jul 27, 2018 at 03:06:02PM +0100, Anthony PERARD wrote:
> The libxl__ev_qmp_* will now send the command to QEMU when the socket is
> ready for writes.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

> ---
>  tools/libxl/libxl_qmp.c | 44 +
>  1 file changed, 44 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 2792f35912..75f953d521 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1326,6 +1326,8 @@ static int qmp_ev_prepare_cmd(libxl__gc *gc,
>  ev->tx_buf = buf;
>  ev->tx_buf_len = len;
>  
> +libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events | POLLOUT);
> +
>  return 0;
>  }
>  
> @@ -1435,6 +1437,43 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
> libxl__ev_qmp *ev, int fd)
>  return 0;
>  }
>  
> +static int qmp_ev_callback_writable(libxl__gc *gc, libxl__ev_qmp *ev, int fd)
> +{
> +int rc;
> +char *buf;
> +size_t len;
> +int buf_fd = -1;

I would name this send_fd.

> +
> +/* No need to call qmp_ev_callback_writable again, everything that needs 
> to
> + * be send for now will be in this call. */
> +libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events & ~POLLOUT);

I think you do this because you need to wait for this command to
complete before queuing another command?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 21/32] libxl_qmp: Simplify qmp_response_type() prototype

On Fri, Jul 27, 2018 at 03:06:03PM +0100, Anthony PERARD wrote:
> Remove the libxl__qmp_handler* argument so the function can be reused
> later in a different context.
> 
> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Jackson 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] docs/xl: Clarify documentation for mem-max and mem-set



On 02/08/2018, 11:24, "George Dunlap"  wrote:

On 08/01/2018 05:16 PM, Lars Kurth wrote:
> 
> 
> On 01/08/2018, 16:41, "George Dunlap"  wrote:
> 
> mem-set is the primary command that users will need to use and
> understand.  Move it first, and clarify the wording; also specify that
> you can't set the target higher than maxmem from the domain config.
> 
> mem-max is actually a pretty useless command at the moment.  Clarify
> that users are not expected to use it; and document all of its quirky
> behavior.
> 
> Signed-off-by: George Dunlap 
> ---
> I'm actully somewhat tempted to take out the entry for mem-max
> entirely -- it's not at all clear to me what anyone would use it for,
> and it's only likely to confuse people.
> 
> Should it be deprecated, if it isn't useful?
> 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Konrad Wilk 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Lars Kurth 
> ---
>  docs/man/xl.pod.1.in | 72 
++--
>  1 file changed, 50 insertions(+), 22 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
> index b74764dcd3..1d3dabf185 100644
> --- a/docs/man/xl.pod.1.in
> +++ b/docs/man/xl.pod.1.in
> @@ -393,40 +393,68 @@ less utilized than a high CPU workload.  
Consider yourself warned.
>  
>  =back
>  
> -=item B I I
> +=item B I I
>  
> -Specify the maximum amount of memory the domain is able to use, 
appending 't'
> -for terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for 
kilobytes and 'b'
> -for bytes.
> +Set the target for the domain's balloon driver.  Append 't' for
> 
> I would say Use instead of Append: if you are not a native speaker you 
could
> be misled that the command appends memory.

I'm afraid 'use' doesn't tell me what to do -- `set-max A t`? `set-max A
2048 t`?  `set-max A t2048`?

What about making a paragraph break and changing it to:

"The default unit is kiB.  Add 't' to specify TiB, 'g' for GiB, 'm' for
MiB, and 'b' for bytes (e.g., 2048m)."

Alternate we could say `I[]`, but that seems to be getting a
little clunky.

I will leave that up to you. It's just something I noticed but not a big deal. 

Lars 

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

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3a0c1bf64b5deaa4e227b311cc43aa1513beae5e
baseline version:
 ovmf 68bef3f0c7c71da2f065fd348efa79f04799d347

Last test of basis   125738  2018-08-02 04:04:21 Z0 days
Testing same since   125740  2018-08-02 09:10:45 Z0 days1 attempts


People who touched revisions under test:
  Yunhua Feng 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   68bef3f0c7..3a0c1bf64b  3a0c1bf64b5deaa4e227b311cc43aa1513beae5e -> 
xen-tested-master

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

Re: [Xen-devel] [xen-4.9-testing test] 125710: regressions - trouble: blocked/broken/fail/pass

On Thu, Aug 02, 2018 at 04:26:10AM -0600, Jan Beulich wrote:
> >>> On 02.08.18 at 12:05,  wrote:
> > flight 125710 xen-4.9-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/125710/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail 
> > REGR. vs. 124328
> 
> This one also failed in 125686. In both cases there is
> 
> error: Timed out during operation: cannot acquire state change lock
> 
> in the test log, which I have no idea what it means.

This is libvirtd's error message.

The remote host can't obtain the state change log due to it is already
held by another task/thread. It could be a libvirt / libxl bug.

2018-08-01 16:12:13.433+: 3491: warning : libxlDomainObjBeginJob:151 : 
Cannot start job (modify) for domain debian.guest.osstest; current job is 
(modify) owned by (24975)

Wei.

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

Re: [Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU

On Fri, Jul 27, 2018 at 03:06:04PM +0100, Anthony PERARD wrote:
> This will handles messages received, and calls callbacks associated with
^ handle

I'm not sure I understand what's 'This' in the context. Would be good
if you could spell out what 'This' refers to IMO.

> the libxl__ev_qmp when the expected response is received.
> 
> This also print error messages from QMP on behalf of the callback.
> 
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
> v4:
> Provide an libxl error code to callbacks on error instead of a
> qmp_error_class
> 
>  tools/libxl/libxl_qmp.c  | 116 +++
>  tools/libxl/libxl_types.idl  |   4 +
>  tools/libxl/libxl_types_internal.idl |   8 ++
>  3 files changed, 128 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index aabf9ad5e7..e649b8054d 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1330,6 +1330,118 @@ static int qmp_ev_prepare_cmd(libxl__gc *gc,
>  return 0;
>  }
>  
> +/*
> + * Handle messages received from QMP server
> + */
> +
> +static int qmp_error_class_to_libxl_error_code(const libxl__qmp_error_class 
> c)
> +{
> +switch (c) {
> +case LIBXL__QMP_ERROR_CLASS_GENERICERROR:
> +return ERROR_QMP_GENERIC_ERROR;
> +case LIBXL__QMP_ERROR_CLASS_COMMANDNOTFOUND:
> +return ERROR_QMP_COMMAND_NOT_FOUND;
> +case LIBXL__QMP_ERROR_CLASS_DEVICENOTACTIVE:
> +return ERROR_QMP_DEVICE_NOT_ACTIVE;
> +case LIBXL__QMP_ERROR_CLASS_DEVICENOTFOUND:
> +return ERROR_QMP_DEVICE_NOT_FOUND;
> +default:
> +abort();
> +}
> +}
> +
> +/* return 1 when a user callback as been called */
> +static int qmp_ev_handle_response(libxl__egc *egc,
> +  libxl__ev_qmp *ev,
> +  const libxl__json_object *resp,
> +  libxl__qmp_message_type type)
> +{
> +EGC_GC;
> +const libxl__json_object *response;
> +const libxl__json_object *o;
> +int rc;
> +int id;
> +
> +o = libxl__json_map_get("id", resp, JSON_INTEGER);
> +if (!o) {
> +const char *error_desc;
> +
> +/* unexpected message, attempt to find an error description */
> +o = libxl__json_map_get("error", resp, JSON_MAP);
> +o = libxl__json_map_get("desc", o, JSON_STRING);
> +error_desc = libxl__json_object_get_string(o);
> +if (error_desc)
> +LOGD(ERROR, ev->domid, "%s", error_desc);
> +else
> +LOGD(ERROR, ev->domid, "Received unexpected message: %s",
> + libxl__json_object_to_json(gc, resp));
> +return 0;
> +}
> +
> +id = libxl__json_object_get_integer(o);
> +if (id != ev->id)
> +return 0;
> +
> +switch (type) {
> +case LIBXL__QMP_MESSAGE_TYPE_RETURN: {
> +response = libxl__json_map_get("return", resp, JSON_ANY);
> +rc = 0;
> +break;
> +}
> +case LIBXL__QMP_MESSAGE_TYPE_ERROR: {
> +const char *s;
> +const libxl__json_object *err;
> +libxl__qmp_error_class error_class;
> +
> +rc = ERROR_FAIL;
> +response = NULL;
> +
> +err = libxl__json_map_get("error", resp, JSON_MAP);
> +o = libxl__json_map_get("class", err, JSON_STRING);
> +s = libxl__json_object_get_string(o);

You could init err and s at definition time.

> +if (s && !libxl__qmp_error_class_from_string(s, &error_class))
> +rc = qmp_error_class_to_libxl_error_code(error_class);
> +
> +o = libxl__json_map_get("desc", err, JSON_STRING);
> +s = libxl__json_object_get_string(o);
> +if (s)
> +LOGD(ERROR, ev->domid, "%s", s);
> +
> +break;
> +}
> +default:
> +abort();
> +}
> +
> +ev->id = -1;
> +ev->callback(egc, ev, response, rc); /* must be last */
> +return 1;
> +}
> +
> +/* return 1 when a user callback as been called */
> +static int qmp_ev_handle_message(libxl__egc *egc,
> + libxl__ev_qmp *ev,
> + const libxl__json_object *resp)
> +{
> +EGC_GC;
> +libxl__qmp_message_type type = qmp_response_type(resp);
> +
> +switch (type) {
> +case LIBXL__QMP_MESSAGE_TYPE_QMP:
> +/* greeting message */
> +return 0;
> +case LIBXL__QMP_MESSAGE_TYPE_RETURN:
> +case LIBXL__QMP_MESSAGE_TYPE_ERROR:
> +return qmp_ev_handle_response(egc, ev, resp, type);
> +case LIBXL__QMP_MESSAGE_TYPE_EVENT:
> +/* Event are ignored */
> +return 0;
> +case LIBXL__QMP_MESSAGE_TYPE_INVALID:
> +return 0;

Might be good to have a 'default' lable here and print some debug
message about receiving an unknown QMP message type?

> +}
> +return 0;
> +}
> +
>  /*
>   * QMP FD callbacks
>   */
> @@ -1432,6 +1544,10 @@ static int qmp_ev_callback_readable(libxl__egc *egc,

[Xen-devel] [RFC] OVMF on PVH

2018-08-02 Thread Anthony PERARD

Hi,

I've been working on booting OVMF in a PVH guest. There are few changes
that I'd like your comments on. Those are changes that I've already made
in my private branch, there are either required or will make things
easier.

## Goal

Have a single blob that can be use for both HVM and PVH guests. And be
able to start UEFI compatible guests in PVH.


## New binary, separated from QEMU/KVM one.

Right now, the rules to build the firmware are located in
`OvmfPkg/OvmfPkgX64.dsc`, a platform. I've created a new platform, without
KVM support, and would like to retire the Xen support from the current
platform.  For now, I have created OvmfPkg/XenOvmf.dsc. (The change to a
new platform had been proposed by upstream.)

That would simplify Xen support in OVMF, and allow to diverge more from
OVMF where needed. That would mostly be useful during the initial boot
phase where there lots of `if xen do that, else do that`.

We can also choose some drivers that can work on both PVH and HVM, for
example, use a LAPIC timer instead of ACPI Timer.

All this mean that building OVMF for Xen would need to be change.


## ELF header

Adding an ELF header to OVMF so the blob can be loaded by libxl/libxc
without modifying those libs.

That replace a section of the OVMF binary called VarStore by that ELF
header.  It's empty and libxl doesn't know how to use it. (QEMU/KVM would
have a flash device loading the store, so it can be written to.)

With the ELF header, I can test OVMF by simply adding this in the config
file:

type='pvh'
kernel='/path/to/OVMF.fd'

We could use a modified `hvmloader` to load OVMF on PVH or teach libxc to
load it at a hardcoded location, but I don't see it as necessary, and if
we have one less firmware to load, it's probably better.

With the use of an ELF header comes another issue, which as to do with
were the binary needs to be loaded initially.

## Loading binary at 0x1 (1MB, like hvmloader on HVM)

Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with
hvmloader moving some RAM around to allow that.  But with the use of an
ELF header, and let libxc load the blob, it was not possible to load the
blob just below 4GB. (Or at least without modification of the toolstack I
guess.) So I've attempted to have OVMF been started from a different place
in memory. Then I had to hack a bit more in order to be able to start OVMF
from two different location (the current one for HVM guest, and a new one
that can be used for PVH). That works fine, I'll just have to find out
what upstream think about that.

## Current WIP

You can find my current branch on xenbits, it still needs to be cleanup
but it works and can boot a PVH guest:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git
branch: wip.platform-xen-pvh

To build: OvmfPkg/build.sh -p OvmfPkg/XenOvmf.dsc -n $number_of_cpu

Thanks,

-- 
Anthony PERARD

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

[Xen-devel] [BUG] docs: our man page generation uses http://man.he.net/ by default which causes broken links. It should be changed to point to a relative path

Hi all,

most of our man pages on pretty much all releases from 4.2 contain broken 
links. 

For example:
In https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html the source contains:

"For more details, see L." 
Maps onto http://man.he.net/man7/xl-numa-placement  (does not exist)

“See L for more details.” 
Maps onto http://man.he.net/man5/xl-disk-configuration (does not exist)

Etc.

There seem to be two issues:
* The root path http://man.he.net, which is incorrect
* The resolution of filenames to man/: should be man/..html

Probably we need to feed some arguments to probably we need to feed some 
arguments 
to pod2html in order to generate the correct urls. See  
https://perldoc.perl.org/pod2html.html 
(maybe we need we need –htmldir). For our docs build, this should probably go 
to 
https://xenbits.xen.org/docs/unstable/man/ while for local installs to 
${prefix}/share/doc/xen/html/man or something like it.

I had a look to see whether I can fix this, but that seems a little too complex 
for me

Regards
Lars

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

Re: [Xen-devel] [BUG] docs: our man page generation uses http://man.he.net/ by default which causes broken links. It should be changed to point to a relative path



On 02/08/2018, 12:24, "Lars Kurth"  wrote:

Hi all,

most of our man pages on pretty much all releases from 4.2 contain broken 
links. 

For example:
In https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html the source 
contains:

"For more details, see L." 
Maps onto http://man.he.net/man7/xl-numa-placement  (does not exist)

“See L for more details.” 

That should read - copy and paste
“See L for more details.”

Maps onto http://man.he.net/man5/xl-disk-configuration (does not exist)

Etc.

There seem to be two issues:
* The root path http://man.he.net, which is incorrect
* The resolution of filenames to man/: should be 
man/..html

Probably we need to feed some arguments to probably we need to feed some 
arguments 
to pod2html in order to generate the correct urls. See  
https://perldoc.perl.org/pod2html.html 
(maybe we need we need –htmldir). For our docs build, this should probably 
go to 
https://xenbits.xen.org/docs/unstable/man/ while for local installs to 
${prefix}/share/doc/xen/html/man or something like it.

I had a look to see whether I can fix this, but that seems a little too 
complex for me

Regards
Lars



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

Re: [Xen-devel] [PATCH v4 23/32] libxl_qmp: Respond to QMP greeting

On Fri, Jul 27, 2018 at 03:06:05PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_qmp.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index e649b8054d..83afce3192 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -1309,6 +1309,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
> domid,
>  
>  /*  Implementation of libxl__ev_qmp  */
>  
> +/* hard coded message ID used for capability negociation */
> +static int qmp_capability_negociation_msgid = 1;

Could this be a define instead? Or at least constify it because it
doesn't seem like it's modified (at least in this patch).

>  static int qmp_ev_prepare_cmd(libxl__gc *gc,
>libxl__ev_qmp *ev,
>const char *cmd,
> @@ -1379,7 +1382,7 @@ static int qmp_ev_handle_response(libxl__egc *egc,
>  }
>  
>  id = libxl__json_object_get_integer(o);
> -if (id != ev->id)
> +if (id != ev->id && id != qmp_capability_negociation_msgid)
>  return 0;
>  
>  switch (type) {
> @@ -1413,9 +1416,21 @@ static int qmp_ev_handle_response(libxl__egc *egc,
>  abort();
>  }
>  
> -ev->id = -1;
> -ev->callback(egc, ev, response, rc); /* must be last */
> -return 1;
> +/*
> + * Even if the current state is capability_negociation and the correct ID
> + * as been received, call the callback on error.
> + */
> +if (ev->qmp_state == qmp_state_capability_negociation &&
> +id == qmp_capability_negociation_msgid &&
> +rc == 0) {
> +ev->qmp_state = qmp_state_connected;
> +libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events | POLLOUT);
> +return 0;
> +} else {
> +ev->id = -1;
> +ev->callback(egc, ev, response, rc); /* must be last */
> +return 1;
> +}
>  }
>  
>  /* return 1 when a user callback as been called */
> @@ -1429,6 +1444,11 @@ static int qmp_ev_handle_message(libxl__egc *egc,
>  switch (type) {
>  case LIBXL__QMP_MESSAGE_TYPE_QMP:
>  /* greeting message */
> +assert(ev->qmp_state == qmp_state_connecting);
> +ev->qmp_state = qmp_state_greeting;
> +/* Allow qmp_ev_callback_writable to be called in order to send
> + * qmp_capabilities */
> +libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events | POLLOUT);
>  return 0;
>  case LIBXL__QMP_MESSAGE_TYPE_RETURN:
>  case LIBXL__QMP_MESSAGE_TYPE_ERROR:
> @@ -1563,7 +1583,11 @@ static int qmp_ev_callback_writable(libxl__gc *gc, 
> libxl__ev_qmp *ev, int fd)
>   * be send for now will be in this call. */
>  libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events & ~POLLOUT);
>  
> -if (ev->qmp_state == qmp_state_connected) {
> +if (ev->qmp_state == qmp_state_greeting) {
> +buf = qmp_prepare_qmp_cmd(gc, "qmp_capabilities", NULL,
> +  qmp_capability_negociation_msgid, &len);
> +ev->qmp_state = qmp_state_capability_negociation;
> +} else if (ev->qmp_state == qmp_state_connected) {

A switch (ev->qmp_state) might be better.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 25/32] libxl_exec: Add libxl__spawn_initiate_failure

On Fri, Jul 27, 2018 at 03:06:07PM +0100, Anthony PERARD wrote:
> This function can be use by user libxl__spawn_* when they setup a
   ^ used and remove user
> notification other than xenstore. The parent can already called success
   ^ report
> via libxl__spawn_initiate_detach(), this new function can be used for
> failure instead of waiting for the timeout.
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

> ---
>  tools/libxl/libxl_exec.c |  7 +++
>  tools/libxl/libxl_internal.h | 21 -
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 02e6c917f0..fb9621b10a 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -373,6 +373,13 @@ void libxl__spawn_initiate_detach(libxl__gc *gc, 
> libxl__spawn_state *ss)
>  spawn_detach(gc, ss);
>  }
>  
> +void libxl__spawn_initiate_failure(libxl__gc *gc, libxl__spawn_state *ss, 
> int rc)
> +{
> +assert(rc);
> +ss->rc = rc;
> +spawn_detach(gc, ss);
> +}
> +
>  static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss, int rc)
>  /* Caller must have logged.  Must be last thing in calling function,
>   * as it may make the callback.  Precondition: Attached or Detaching. */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 110b951bbe..b94657a7f0 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1551,7 +1551,8 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
>   *
>   * The inner child must soon exit or exec.  It must also soon exit or
>   * notify the parent of its successful startup by writing to the
> - * xenstore path xspath.
> + * xenstore path xspath OR via other mean that the parent will have
^ means
> + * to setup.
>   *
>   * The user (in the parent) will be called back (confirm_cb) every
>   * time that xenstore path is modified.
> @@ -1607,6 +1608,24 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, 
> libxl__spawn_state *spawn);
>   */
>  _hidden void libxl__spawn_initiate_detach(libxl__gc *gc, 
> libxl__spawn_state*);
>  
> +/*
> + * libxl__spawn_initiate_failure - Propagate failure from the caller to the
> + * callee.
> + *
> + * Works by killing the intermediate process from spawn_spawn.
> + * After this function returns, failures will be reported via failure_cb.
> + *
> + * This is not synchronous: there will be a further callback when
> + * the detach is complete.
> + *
> + * Logs errors.
> + *
> + * The spawn state must be Attached entry and will be Attached Failed
> + * on return.
> + */
> +_hidden void libxl__spawn_initiate_failure(libxl__gc *gc,
> +   libxl__spawn_state *ss, int rc);
> +
>  /*
>   * If successful, this should return 0.
>   *
> -- 
> Anthony PERARD
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH v8 00/11] arm: more kconfig configurability and small default configs


Hi Stefano,

On 31/07/18 17:10, Stefano Stabellini wrote:

On Tue, 31 Jul 2018, Julien Grall wrote:

On 30/07/18 18:48, Stefano Stabellini wrote:

Hi all,


Hi Stefano,



This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.

The series makes a few changes to allow disabling more kconfig options:
most of them already exist but cannot be disabled. It also introduces a
reference kconfig for Renesas RCar (due to popular demand, candidate for
certifications), Xilinx MPSoC, and for QEMU aarch64 (not for
certifications, but useful for debugging).

The last patch clarifies the security support status of kconfig options
in Xen.

All patches are already acked, except for patch #8: "arm: add ALL_PLAT,
QEMU, Rcar3 and MPSoC configs".

Cheers,

Stefano


The following changes since commit 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5:

docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again
(2018-04-13 17:04:36 +0100)


This is nearly 4 months old... Please resend the series rebased on the latest
staging.


This is the rebase on staging, let me know if you would also like me to
send it to the list. This branch is exactly identical to v8 (aside from
the first patch being dropped): I haven't done Jan's small request for
change. Let me know if you prefer that I do.


I addressed Jan's small request and committed.

Cheers,

--
Julien Grall

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

[Xen-devel] xen-tools-4.4.4 (SLES11): Unexpected error:

2018-08-02 Thread Ulrich Windl

Hi!

WHen using "xm list test12 -l" that seems to be in pvgrub state, I get this 
error:
---
Unexpected error: 

Please report to xen-de...@lists.xen.org 
Traceback (most recent call last):
  File "/usr/sbin/xm", line 20, in 
main.main(sys.argv)
  File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3976, in main
_, rc = _run_cmd(cmd, cmd_name, args)
  File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 4000, in 
_run_cmd
return True, cmd(args)
  File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 1044, in 
xm_list
doms = getDomains(params, state, use_long, pool)
  File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 991, in 
getDomains
return [server.xend.domain(dom, full) for dom in domain_names]
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/site-packages/xen/util/xmlrpcclient.py", line 124, 
in __request
response = xmlrpclib.ServerProxy.__request(self, methodname, params)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
verbose=self.__verbose
  File "/usr/lib64/python2.6/site-packages/xen/util/xmlrpcclient.py", line 56, 
in request
request_body, verbose)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request
return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1387, in _parse_response
p.feed(response)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 601, in feed
self._parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 280, column 
25
---

From strace I can see this output (why are you receiving HTTP responses one 
character at a time, BTW?):
---
recvfrom(3, "H", 1, 0, NULL, NULL)  = 1
recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
recvfrom(3, "T", 1, 0, NULL, NULL)  = 1
recvfrom(3, "P", 1, 0, NULL, NULL)  = 1
recvfrom(3, "/", 1, 0, NULL, NULL)  = 1
recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
recvfrom(3, ".", 1, 0, NULL, NULL)  = 1
recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
recvfrom(3, " ", 1, 0, NULL, NULL)  = 1
recvfrom(3, "2", 1, 0, NULL, NULL)  = 1
recvfrom(3, "0", 1, 0, NULL, NULL)  = 1
recvfrom(3, "0", 1, 0, NULL, NULL)  = 1
recvfrom(3, " ", 1, 0, NULL, NULL)  = 1
recvfrom(3, "O", 1, 0, NULL, NULL)  = 1
recvfrom(3, "K", 1, 0, NULL, NULL)  = 1
recvfrom(3, "\r", 1, 0, NULL, NULL) = 1
[...]
recvfrom(3, "\n", 1, 0, NULL, NULL) = 1
recvfrom(3, "C", 1, 0, NULL, NULL)  = 1
recvfrom(3, "o", 1, 0, NULL, NULL)  = 1
recvfrom(3, "n", 1, 0, NULL, NULL)  = 1
recvfrom(3, "t", 1, 0, NULL, NULL)  = 1
recvfrom(3, "e", 1, 0, NULL, NULL)  = 1
recvfrom(3, "n", 1, 0, NULL, NULL)  = 1
recvfrom(3, "t", 1, 0, NULL, NULL)  = 1
recvfrom(3, "-", 1, 0, NULL, NULL)  = 1
recvfrom(3, "L", 1, 0, NULL, NULL)  = 1
recvfrom(3, "e", 1, 0, NULL, NULL)  = 1
recvfrom(3, "n", 1, 0, NULL, NULL)  = 1
recvfrom(3, "g", 1, 0, NULL, NULL)  = 1
recvfrom(3, "t", 1, 0, NULL, NULL)  = 1
recvfrom(3, "h", 1, 0, NULL, NULL)  = 1
recvfrom(3, ":", 1, 0, NULL, NULL)  = 1
recvfrom(3, " ", 1, 0, NULL, NULL)  = 1
recvfrom(3, "1", 1, 0, NULL, NULL)  = 1
recvfrom(3, "2", 1, 0, NULL, NULL)  = 1
recvfrom(3, "5", 1, 0, NULL, NULL)  = 1
recvfrom(3, "8", 1, 0, NULL, NULL)  = 1
recvfrom(3, "3", 1, 0, NULL, NULL)  = 1
recvfrom(3, "\r", 1, 0, NULL, NULL) = 1
recvfrom(3, "\n", 1, 0, NULL, NULL) = 1
recvfrom(3, "\r", 1, 0, NULL, NULL) = 1
recvfrom(3, "\n", 1, 0, NULL, NULL) = 1
recvfrom(3, "\n\n\n\n
\ndomain\n\ndomid\n23\n\n\ncpu_weight\n256\n\n\ncpu_cap\n0\n
\n\npool_name\nPool-0\n\n
\nbootloader\n\n
\n\nvcpus\n2\n\n
\ncpus\n\n\n\n\n\n\n\n\non_poweroff\ndestroy\n\n\ndescription\nT
est for SLES12\n\n\n
on_crash\ndestroy\n\n\nuuid\n33fd1b55-5048-b924-89f7-7badd34fd04f\n\n\nbootloader_args\n\n\n
\nname\ntest12\n\n\non_re
boot\nrestart\n<
/value>\n\nmaxmem\n4096\n\n\nmemory\n1024\n\n\nshadow_memory\n0<
/value>\n\n\nfeatures<
/string>\n\n\n\non_xend_start\nignore\n\n\n
on_xend_stop\nignore\n<
/data>\n\nstart_time
\n153323.9450271\n\n\ncpu_time\n468.0904554252\n\n\nonline_vcpus\n1\n\n", 1024, 0, NULL, NULL) = 1024
recvfrom(3, "\nimage\n\nlinux\n\nkernel\n/usr/lib/grub2/x86_64-xen/gr
ub.xen\n\n\n<
string>args\n(hd1,0)/boot/grub/menu.lst
\n\n\nsuperpag
es\n0\n\n\nvideoram\n4\n\n\npci\n\n\n\n\nnomigrate\n0\n\n\n
tsc_mode\n0\n\
n\n<", 1024, 0, NULL, NULL) = 1024
recvfrom(3, "string>notes\n\nENTRY\n0\n\n\nXEN_VERSION\n<
string>xen-3.0\n\n\n
GUEST_OS\nGRUB2\
n\n\nVIRT_BASE\n0\n\n\nLOADER\ngeneric\n\n\n<
/value>\n\n\nstatus\n2\n\n\nstate\nr-\n\n\nstore_m
fn\n25971146\n\n\nconsole_mfn\n25971145\n\n\ndevice\n\nvif\n
\nbridge\nbr0\n\n\nmac\n00:16:3e:7b:40:1d\n\n\nscript\n/etc/xen/scripts/vif-bridge\n\n
\nuuid\n9eddd
812-cd72-29dd-6ad6-b59221548b00\n\n\nbackend\n0\n\n\n
\n\ndevice\n\nvif\n\nbridge\nbr1\n\n\nmac\n00:16:3e:76:0f:d
b\n\n\ns

Re: [Xen-devel] [RFC] OVMF on PVH

>>> On 02.08.18 at 13:24,  wrote:
> ## New binary, separated from QEMU/KVM one.
> 
> Right now, the rules to build the firmware are located in
> `OvmfPkg/OvmfPkgX64.dsc`, a platform. I've created a new platform, without
> KVM support, and would like to retire the Xen support from the current
> platform.  For now, I have created OvmfPkg/XenOvmf.dsc. (The change to a
> new platform had been proposed by upstream.)
> 
> That would simplify Xen support in OVMF, and allow to diverge more from
> OVMF where needed. That would mostly be useful during the initial boot
> phase where there lots of `if xen do that, else do that`.
> 
> We can also choose some drivers that can work on both PVH and HVM, for
> example, use a LAPIC timer instead of ACPI Timer.
> 
> All this mean that building OVMF for Xen would need to be change.

And users / tool stacks having to pick the right binary.

> ## Loading binary at 0x1 (1MB, like hvmloader on HVM)
> 
> Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with
> hvmloader moving some RAM around to allow that.  But with the use of an
> ELF header, and let libxc load the blob, it was not possible to load the
> blob just below 4GB. (Or at least without modification of the toolstack I
> guess.) So I've attempted to have OVMF been started from a different place
> in memory. Then I had to hack a bit more in order to be able to start OVMF
> from two different location (the current one for HVM guest, and a new one
> that can be used for PVH). That works fine, I'll just have to find out
> what upstream think about that.

I'm of two minds here - as a firmware binary, it doesn't seem to make
sense to load at 0x10, yet as a hvmloader replacement it might.
However, parts of it will need to stay (runtime services code/data),
and such permanent data better lives at higher addresses imo.

Jan



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

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

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 125729

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

version targeted for testing:
 xen  4c9a6546e4c33ba2b170d5c1d0c340c1dd384ffc
baseline version:
 xen  ed5f8d9ca47e69e30221c37ec812f2b38af19d83

Last test of basis   125729  2018-08-01 11:00:39 Z1 days
Testing same since   125741  2018-08-02 10:01:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Kevin Tian 

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



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 4c9a6546e4c33ba2b170d5c1d0c340c1dd384ffc
Author: Andrew Cooper 
Date:   Wed Jan 24 16:59:42 2018 +

xen: Remove domain_crash_synchronous() completely

domain_crash_synchronous() is unsafe to use in general as it may leave
spinlocks held, temporary memory allocated, etc.

With domain_crash_synchronous() removed from the ARM code in 4.11, take the
opportunity to remove the infrastructure completely by opencoding the 
softirq
loop in the remaining callsites, all of which are destined for deletion.

None of these sites are at risk of having a pending ioreq to qemu, which 
means
that the vcpu_end_shutdown_deferral() isn't necessary.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: Roger Pau Monné 

commit 499a76634d74f4ec663629fe85239e05d0352bb9
Author: Andrew Cooper 
Date:   Tue Feb 6 12:01:08 2018 +

x86/vmx: Avoid using domain_crash_syncrhonous() in vmx_vmentry_failure()

There is no need for the syncrhonous varient, as the vmentry failure path 
can
just return to processing softirqs.

This is in aid of trying to remove domain_crash_syncrhonous() from the
codebase.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Acked-by: Kevin Tian 

commit 48dbb2dbe9d9f92a2890a15bb48a0598c065b9f8
Author: Andrew Cooper 
Date:   Wed Aug 1 12:47:50 2018 +0100

x86/vmx: Avoid hitting BUG_ON() after EPTP-related domain_crash()

If the EPTP pointer can't be located in the altp2m list, the domain
is (legitimately) crashed.

Under those circumstances, execution will continue and guarentee to hit the
BUG_ON(idx >= MAX_ALTP2M) (unfortunately, just out of context).

Return from vmx_vmexit_handler() after the domain_crash(), which also has 
the
side effect of reentering the scheduler more promptly.

Signed-off-by: Andrew Cooper 
Reviewed-by: Razvan Cojocaru 
Acked-by: Kevin Tian 
(qemu changes not included)

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

[Xen-devel] [PATCH 0/2] docs: fix various out-of-date links in man pages

Lars Kurth (2):
  Point links to new location of the TPM Emulator formerly hosted on
Berlios
  Point to new location of Virtual Machine Generation ID

 docs/man/xen-vtpm.pod.7  | 2 +-
 docs/man/xl.cfg.pod.5.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.13.0


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

[Xen-devel] [PATCH 1/2] Point links to new location of the TPM Emulator formerly hosted on Berlios

Signed-off-by: Lars Kurth 
---
 docs/man/xen-vtpm.pod.7 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/man/xen-vtpm.pod.7 b/docs/man/xen-vtpm.pod.7
index 8de67f4d94..52721e6c83 100644
--- a/docs/man/xen-vtpm.pod.7
+++ b/docs/man/xen-vtpm.pod.7
@@ -374,4 +374,4 @@ C will copy pcrs 5, 12, 13, 14, 15, and 
16.
 
 =head1 REFERENCES
 
-Berlios TPM Emulator: L
+Berlios TPM Emulator: L
-- 
2.13.0


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

[Xen-devel] [PATCH 2/2] Point to new location of Virtual Machine Generation ID

Signed-off-by: Lars Kurth 
---
 docs/man/xl.cfg.pod.5.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index b72718151b..539bf7fe78 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -2054,7 +2054,7 @@ Do not provide a VM generation ID.
 =back
 
 See also "Virtual Machine Generation ID" by Microsoft:
-L
+L
 
 =back 
 
-- 
2.13.0


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

Re: [Xen-devel] [PATCH 1/2] Point links to new location of the TPM Emulator formerly hosted on Berlios

On Thu, Aug 02, 2018 at 01:40:23PM +0100, Lars Kurth wrote:
> Signed-off-by: Lars Kurth 
> ---
>  docs/man/xen-vtpm.pod.7 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/man/xen-vtpm.pod.7 b/docs/man/xen-vtpm.pod.7
> index 8de67f4d94..52721e6c83 100644
> --- a/docs/man/xen-vtpm.pod.7
> +++ b/docs/man/xen-vtpm.pod.7
> @@ -374,4 +374,4 @@ C will copy pcrs 5, 12, 13, 14, 15, 
> and 16.
>  
>  =head1 REFERENCES
>  
> -Berlios TPM Emulator: L
> +Berlios TPM Emulator: L

This seems to be pointing to a personal account. If we really care, we
should create a tree ourselves.

Wei.

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

Re: [Xen-devel] [PATCH 2/2] Point to new location of Virtual Machine Generation ID

On Thu, Aug 02, 2018 at 01:40:24PM +0100, Lars Kurth wrote:
> Signed-off-by: Lars Kurth 
> ---
>  docs/man/xl.cfg.pod.5.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index b72718151b..539bf7fe78 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -2054,7 +2054,7 @@ Do not provide a VM generation ID.
>  =back
>  
>  See also "Virtual Machine Generation ID" by Microsoft:
> -L
> +L

Acked-by: Wei Liu 

Ideally we should use a permalink if available, but there isn't one for
that page.

Wei.

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

[Xen-devel] [ovmf baseline-only test] 75036: tolerable FAIL

2018-08-02 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 75036 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75036/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75031
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75031

version targeted for testing:
 ovmf 7343bc8062c893ed6d40b25a9329d51340e0d703
baseline version:
 ovmf 6d9a0a9420167a87d353b53b93fec17ad61b4b61

Last test of basis75031  2018-07-31 21:54:06 Z1 days
Testing same since75036  2018-08-01 17:53:04 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

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  fail



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


commit 7343bc8062c893ed6d40b25a9329d51340e0d703
Author: Dandan Bi 
Date:   Mon Jul 30 09:59:47 2018 +0800

ShellPkg/UefiShellAcpiViewCommandLib: Fix GCC build failure

Fix following GCC build issues:
1.
xxx/SratParser.c:127:47: error:
initialization from incompatible pointer type
[-Werror=incompatible-pointer-types]
{L"Proximity Domain [31:8]", 3, 9, L"0x%x", DumpSratApicProximity,
^
xxx/SratParser.c:127:47: note:
(near initialization for 'SratApciSapicAffinityParser[6].PrintFormatter')

2.
xxx\UefiShellAcpiViewCommandLib.c:66:14:
error: 'Status' may be used uninitialized in this fu
nction [-Werror=maybe-uninitialized]
   EFI_STATUS Status;
  ^

cc: Alexei Fedorov 
cc: Ruiyu Ni 
cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
Reviewed-by: Jaben Carsey 

commit e6f958d15d710da19dca3fb38943d83f1b3532d6
Author: Dandan Bi 
Date:   Mon Jul 30 09:31:36 2018 +0800

ShellPkg/UefiShellAcpiViewCommandLib: Fix VS2012 build failure

Fix following build error:
UefiShellAcpiViewCommandLib\AcpiParser.c(519) :
error C2308: concatenating mismatched strings
Concatenating wide "ERROR: %a: Offset Mismatch for %s"
with narrow "CurrentOffset = %d FieldOffset = %d"

cc: Alexei Fedorov 
cc: Ruiyu Ni 
cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
Reviewed-by: Jaben Carsey 

commit ed8746801e0d9a5fc5fec006efdedac1c09e7bbf
Author: Dandan Bi 
Date:   Mon Jul 30 09:25:11 2018 +0800

ShellPkg/UefiShellAcpiViewCommandLib: Fix VS2012 build failure

Fix following build error:
xxx\AcpiParser.c(487) : error C2275: 'UINTN' :
illegal use of this type as an expression
xxx\ProcessorBind.h(224) : see declaration of 'UINTN'
xxx\AcpiParser.c(487) : error C2146: syntax error :
missing ';' before identifier 'OriginalAttribute'
xxx\AcpiParser.c(487) : error C2065: 'OriginalAttribute' :
undeclared identifier
..

cc: Alexei Fedorov 
cc: Ruiyu Ni 
cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
Reviewed-by: Jaben Carsey 

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

Re: [Xen-devel] [PATCH 1/2] Point links to new location of the TPM Emulator formerly hosted on Berlios



On 02/08/2018, 13:57, "Wei Liu"  wrote:

On Thu, Aug 02, 2018 at 01:40:23PM +0100, Lars Kurth wrote:
> Signed-off-by: Lars Kurth 
> ---
>  docs/man/xen-vtpm.pod.7 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/man/xen-vtpm.pod.7 b/docs/man/xen-vtpm.pod.7
> index 8de67f4d94..52721e6c83 100644
> --- a/docs/man/xen-vtpm.pod.7
> +++ b/docs/man/xen-vtpm.pod.7
> @@ -374,4 +374,4 @@ C will copy pcrs 5, 12, 13, 14, 
15, and 16.
>  
>  =head1 REFERENCES
>  
> -Berlios TPM Emulator: L
> +Berlios TPM Emulator: L

This seems to be pointing to a personal account. If we really care, we
should create a tree ourselves. 

Adding Christopher Clark and Rich: maybe they know of a better location for 
this. This is the only location I found, but maybe there is a better one
Lars



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

Re: [Xen-devel] [PATCH] tools: fix python shebangs to use /usr/bin/env

2018-08-02 Thread Anthony PERARD

On Thu, Aug 02, 2018 at 11:05:27AM +0200, Roger Pau Monne wrote:
> The path to the python binary can be different from /usr/bin/python
> depending on the distro/OS.

Shouldn't we also s/python/python2/ as recommended by
https://www.python.org/dev/peps/pep-0394/ ?

I don't think all those scripts works with python2 and python3.

-- 
Anthony PERARD

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

Re: [Xen-devel] PVH dom0 creation fails - the system freezes

Please try to avoid top posting.

On Thu, Aug 02, 2018 at 11:36:26AM +, Bercaru, Gabriel wrote:
> I applied the match mentioned, but the system fails to boot. Instead, it
> drops to a BusyBox shell. It seems to be a file system issue.

So you have applied 173c7803592065d27bf2e60d50e08e197a0efa83 and it
causes a regression for you?

As I understand it, before applying 173c780359206 you where capable of
booting the PVH Dom0, albeit with non-working USB?

And after applying 173c780359206 you are no longer able to boot?

> Following is a sequence of the boot log regarding the file system issue.

At least part of the issue seems to be that the IO-APIC information
provided to Dom0 is wrong (from the attached log):

[0.00] IOAPIC[0]: apic_id 2, version 152, address 0xfec0, GSI 0-0
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.00] ERROR: Unable to locate IOAPIC for GSI 2
[0.00] Failed to find ioapic for gsi : 2
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[0.00] ERROR: Unable to locate IOAPIC for GSI 9
[0.00] Failed to find ioapic for gsi : 9
[0.00] ERROR: Unable to locate IOAPIC for GSI 1
[0.00] ERROR: Unable to locate IOAPIC for GSI 2
[0.00] ERROR: Unable to locate IOAPIC for GSI 3
[0.00] ERROR: Unable to locate IOAPIC for GSI 4
[0.00] ERROR: Unable to locate IOAPIC for GSI 5
[0.00] ERROR: Unable to locate IOAPIC for GSI 6
[0.00] ERROR: Unable to locate IOAPIC for GSI 7
[0.00] ERROR: Unable to locate IOAPIC for GSI 8
[0.00] ERROR: Unable to locate IOAPIC for GSI 9
[0.00] ERROR: Unable to locate IOAPIC for GSI 10
[0.00] ERROR: Unable to locate IOAPIC for GSI 11
[0.00] ERROR: Unable to locate IOAPIC for GSI 12
[0.00] ERROR: Unable to locate IOAPIC for GSI 13
[0.00] ERROR: Unable to locate IOAPIC for GSI 14
[0.00] ERROR: Unable to locate IOAPIC for GSI 15

Can you try to boot with just the staging branch (current commit is
008a8fb249b9d433) and see how that goes?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] tools: fix python shebangs to use /usr/bin/env

On Thu, Aug 02, 2018 at 02:49:25PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 11:05:27AM +0200, Roger Pau Monne wrote:
> > The path to the python binary can be different from /usr/bin/python
> > depending on the distro/OS.
> 
> Shouldn't we also s/python/python2/ as recommended by
> https://www.python.org/dev/peps/pep-0394/ ?
> 
> I don't think all those scripts works with python2 and python3.

Oh, maybe. I think however this should be done in a separate patch.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] tools: fix python shebangs to use /usr/bin/env

On Thu, Aug 02, 2018 at 02:49:25PM +0100, Anthony PERARD wrote:
> On Thu, Aug 02, 2018 at 11:05:27AM +0200, Roger Pau Monne wrote:
> > The path to the python binary can be different from /usr/bin/python
> > depending on the distro/OS.
> 
> Shouldn't we also s/python/python2/ as recommended by
> https://www.python.org/dev/peps/pep-0394/ ?
> 
> I don't think all those scripts works with python2 and python3.

This is a good point.

Wei.

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

[Xen-devel] [xen-4.8-testing baseline-only test] 75035: regressions - FAIL

2018-08-02 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 75035 xen-4.8-testing real [real]
http://osstest.xensource.com/osstest/logs/75035/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
75021
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail REGR. vs. 75021

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

version targeted for testing:
 xen  aa450153f2d960c217149b31b68a8b57c5a8e595
baseline version:
 xen  4801bf528c01deed7a315cfe7ff59e8fc94d9733

Last test of basis75021  2018-07-28 15:16:20 Z4 days
Testing same since75035  2018-08-01 17:46:26 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Lars Kurth 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5

Re: [Xen-devel] [RFC PATCH 09/17] libxl: use \x1b to separate qemu arguments for linux stubdomain

2018-08-02 Thread Jason Andryuk

On Wed, Aug 1, 2018 at 9:54 PM Simon Gaiser
 wrote:
>
> Simon Gaiser:
> > Marek Marczykowski-Górecki:
> >> On Wed, Aug 01, 2018 at 10:36:26AM -0400, Jason Andryuk wrote:
> >>> On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
> >>>  wrote:
>  This allows using arguments with spaces, like -append.
>  Stubdomain side of this require "xenstore-client: Add option for raw
>  in-/output" commit.
> >>>
> >>> I had to look up \x1b - it is ascii escape.  Since I was on the
> >>> www.asciitable.com, I saw \x1e is "record seperator" which might make
> >>> more sense.
> >>
> >> Simon, do you remember why you used \x1b? Otherwise indeed changing to
> >> \x1e would make sense.
> >
> > As far as I recall it's a mostly arbitrary choice. I think I choose 0x1b
> > because I thought that ASCII escape would be very unlikely to ever
> > appear in an cmdline. 0x00 would be even better but you don't want to
> > handle 0x00 in bash. I'm not aware of a problem with 0x1e.
>
> PS: If you follow the Wikipedia description [1] of the "separator"
> control characters 0x1f would fit even better. But I don't think it
> really matters what rare character we use.

Agreed. The choice shouldn't matter as long as it's a non-printable ascii char.

> [1]: https://en.wikipedia.org/wiki/C0_and_C1_control_codes#FS

Regards,
Jason

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

Re: [Xen-devel] [RFC PATCH 03/17] libxl: Handle Linux stubdomain specific QEMU options.

2018-08-02 Thread Jason Andryuk

On Wed, Aug 1, 2018 at 11:55 AM Marek Marczykowski-Górecki
 wrote:
>
> On Wed, Aug 01, 2018 at 10:25:22AM -0400, Jason Andryuk wrote:
> > On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
> >  wrote:
> > > From: Eric Shelton 
> > >
> > > This patch creates an appropriate command line for the QEMU instance
> > > running in a Linux-based stubdomain.
> > >
> > > NOTE: a number of items are not currently implemented for Linux-based
> > > stubdomains, such as:
> > > - save/restore
> > > - QMP socket
> > > - graphics output (e.g., VNC)
> > >
> > > Signed-off-by: Eric Shelton 
> > >
> > > Simon:
> > >  * fix disk path
> > >  * fix cdrom path and "format"
> > >  * pass downscript for network interfaces
> > > ---
> > 
> > > @@ -1099,10 +1118,21 @@ static int 
> > > libxl__build_device_model_args_new(libxl__gc *gc,
> > >  return ERROR_INVAL;
> > >  }
> > >  if (b_info->u.hvm.serial) {
> > > -flexarray_vappend(dm_args,
> > > -  "-serial", b_info->u.hvm.serial, NULL);
> > > +if (is_stubdom) {
> > > +flexarray_vappend(dm_args,
> > > +  "-serial",
> > > +  GCSPRINTF("/dev/hvc%d", 
> > > STUBDOM_CONSOLE_SERIAL),
> > > +  NULL);
> > > +} else {
> > > +flexarray_vappend(dm_args,
> > > +  "-serial", b_info->u.hvm.serial, 
> > > NULL);
> > > +}
> > >  } else if (b_info->u.hvm.serial_list) {
> > >  char **p;
> > > +if (is_stubdom) {
> > > +flexarray_vappend(dm_args,
> > > +  "-serial", "/dev/hvc1", NULL);
> >
> > Should this also be GCSPRINTF("/dev/hvc%d", STUBDOM_CONSOLE_SERIAL)
> > instead of hardcoding hvc1?
>
> Yes. Anyway,  multiple serial consoles are incompatible with
> stubdomain anyway - should it error out if serial_list have multiple
> elements? Or silently ignore others?

I think error-ing out with a suitable message for multiple elements
would avoid confusion.  Silently ignoring would leave users wondering
why the extra consoles didn't show up.

Multiple serials could be supported by dynamically allocating more
consoles to stubdom, but it's probably not worth the effort.

> > > +}
> > >  for (p = b_info->u.hvm.serial_list;
> > >   *p;
> > >   p++) {
> >
> > 
> >
> > > @@ -1550,8 +1584,8 @@ static int 
> > > libxl__build_device_model_args_new(libxl__gc *gc,
> > >
> > >  if (disks[i].is_cdrom) {
> > >  drive = libxl__sprintf(gc,
> > > - 
> > > "if=ide,index=%d,readonly=on,media=cdrom,id=ide-%i",
> > > - disk, dev_number);
> > > + "if=ide,readonly=on,media=cdrom,id=ide-%i",
> > > + dev_number);
> >
> > What is the impact of dropping index?
>
> Leftover from Qubes-specific part of this patch (non-cdrom disks are
> converted to SCSI for readonly support, dropping index avoids hitting
> IDE limitation of 4 disks). I'll remove this chunk.

Ah, okay.

Regards,
Jason

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

Re: [Xen-devel] [RFC PATCH 05/17] libxl: use xenstore for pci hotplug qemu-in-linux-stubdom commands

2018-08-02 Thread Jason Andryuk

On Wed, Aug 1, 2018 at 12:03 PM Marek Marczykowski-Górecki
 wrote:
>
> On Wed, Aug 01, 2018 at 10:29:07AM -0400, Jason Andryuk wrote:
> > On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
> >  wrote:
> > > From: Simon Gaiser 
> > >
> > > There is no QMP socket access, re-use the same mechanism as for MiniOS
> > > based stubdom.
> >
> > Later you add some QMP support.  Is this preferred because your QMP
> > support is unreliable?
>
> For now, until final decision how to connect QMP is made, yes.
> This is also somethings we already use Qubes for almost a year, so it
> got much more testing.
>
> But if we get stable QMP support, this patch could be dropped.
>
> > 
> >
> > > @@ -1010,7 +1011,15 @@ static int do_pci_add(libxl__gc *gc, uint32_t 
> > > domid, libxl_device_pci *pcidev, i
> > >  rc = qemu_pci_add_xenstore(gc, domid, pcidev);
> > >  break;
> > >  case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > > -rc = libxl__qmp_pci_add(gc, domid, pcidev);
> > > +dm_domid = libxl_get_stubdom_id(ctx, domid);
> > > +
> > > +if (dm_domid != 0
> > > +&& libxl__stubdomain_version_running(gc, dm_domid) ==
> > > + LIBXL_STUBDOMAIN_VERSION_LINUX) {
> > > +rc = qemu_pci_add_xenstore(gc, domid, pcidev);
> > > +} else {
> > > +rc = libxl__qmp_pci_add(gc, domid, pcidev);
> > > +}
> >
> > What about refactoring the whole switch statement to something like:
> > bool use_qmp = libxl__device_model_version_running(gc, domid)
> >  == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN &&
> >libxl_get_stubdom_id(ctx, domid) == 0;
> > if (use_qmp) {
> >rc = libxl__qmp_pci_add(gc, domid, pcidev);
> > } else {
> > rc = qemu_pci_add_xenstore(gc, domid, pcidev);
> > }
>
> That indeed looks better. But I'd delay touching this patch until
> getting some plan on QMP.

Ok.  That sounds good.

Regards,
Jason

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

Re: [Xen-devel] [PATCH v4 26/32] libxl_dm: Pre-open QMP socket for QEMU

On Fri, Jul 27, 2018 at 03:06:08PM +0100, Anthony PERARD wrote:
> When starting QEMU with dm_restrict=1, pre-open the QMP socket before
> exec QEMU. That socket will be usefull to findout if QEMU is ready, and
> pre-opening it means that libxl can connect to it without waiting for
> QEMU to create it.
> 
> The pre-openning is conditionnal, based on the use of dm_restrict
> because it is using a new command line option of QEMU, and dm_restrict
> support in QEMU is newer.
> 
> -chardev socket,fd=X is available with QEMU 2.12, since commit:
> > char: allow passing pre-opened socket file descriptor at startup
> > 0935700f8544033ebbd41e1f13cd528f8a58d24d
> 
> dm_restrict will be available in QEMU 3.0.
> 
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
> v4:
> separate the logic to open a socket into a function.
> Use libxl__prepare_sockaddr_un() to check path size
> 
>  tools/libxl/libxl_dm.c | 86 +-
>  1 file changed, 77 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 5c28a0ced4..9e3e501457 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -24,6 +24,8 @@
>  #include 
>  #include 
>  #include 
> +#include 

sys/socket.h should be already included by libxl_internal.h

> +#include 

I would probably consider adding sys/un.h to libxl_internal.h unless
it's only required for this specific file.

>  
>  static const char *libxl_tapif_script(libxl__gc *gc)
>  {
> @@ -915,12 +917,58 @@ const char *libxl__qemu_qmp_path(libxl__gc *gc, int 
> domid)
>  return GCSPRINTF("%s/qmp-libxl-%d", libxl__run_dir_path(), domid);
>  }
>  
> +static int libxl__pre_open_qmp_socket(libxl__gc *gc, int domid, int *fd_r)
> +{
> +int rc;
> +int fd = -1;

There's no need to init fd to -1.

> +struct sockaddr_un un;
> +const char *path;
> +
> +path = libxl__qemu_qmp_path(gc, domid);

You can init it a definition time.

> +
> +fd = socket(AF_UNIX, SOCK_STREAM, 0);
> +if (fd < 0) {
> +LOGED(ERROR, domid, "socket() failed");
> +return ERROR_FAIL;
> +}
> +
> +rc = libxl__prepare_sockaddr_un(gc, &un, path, "QEMU's QMP socket");
> +if (rc)
> +goto out;
> +
> +if (unlink(path) < 0 && errno != ENOENT) {
> +LOGED(ERROR, domid, "unlink('%s') failed", path);
> +rc = ERROR_FAIL;
> +goto out;
> +}

You can use libxl__remove_file which also handles EINTR.

> +
> +if (bind(fd, (struct sockaddr*) &un, sizeof(un)) < 0) {
> +LOGED(ERROR, domid, "bind('%s') failed", path);
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +if (listen(fd, 1) < 0) {
> +LOGED(ERROR, domid, "listen() failed");
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +*fd_r = fd;
> +rc = 0;
> +
> +out:
> +if (rc && fd >= 0)
> +close(fd);
> +return rc;
> +}
> +
>  static int libxl__build_device_model_args_new(libxl__gc *gc,
>  const char *dm, int guest_domid,
>  const libxl_domain_config 
> *guest_config,
>  char ***args, char ***envs,
>  const libxl__domain_build_state 
> *state,
> -int *dm_state_fd)
> +int *dm_state_fd, int *dm_monitor_fd)
>  {
>  const libxl_domain_create_info *c_info = &guest_config->c_info;
>  const libxl_domain_build_info *b_info = &guest_config->b_info;
> @@ -949,10 +997,25 @@ static int libxl__build_device_model_args_new(libxl__gc 
> *gc,
>GCSPRINTF("%d", guest_domid), NULL);
>  
>  flexarray_append(dm_args, "-chardev");
> -flexarray_append(dm_args,
> - GCSPRINTF("socket,id=libxl-cmd,"
> -   "path=%s,server,nowait",
> -   libxl__qemu_qmp_path(gc, guest_domid)));
> +/* If we have to use dm_restrict, QEMU need to be new enough and will 
> have
> + * the new interface where we can pre-open the QMP socket. */
> +if (libxl_defbool_val(b_info->dm_restrict))
> +{
> +int rc;
> +
> +rc = libxl__pre_open_qmp_socket(gc, guest_domid, dm_monitor_fd);
> +if (rc)
> +return rc;
> +
> +flexarray_append(dm_args,
> + GCSPRINTF("socket,id=libxl-cmd,fd=%d,server,nowait",
> +   *dm_monitor_fd));
> +} else {
> +flexarray_append(dm_args,
> + GCSPRINTF("socket,id=libxl-cmd,"
> +   "path=%s,server,nowait",
> +   libxl__qemu_qmp_path(gc, guest_domid)));
> +}
>  
>  flexarray_append(dm_args, "-no-shutdown");
>  flexarray_append(dm_args, "-mon");
> @@ -1731,7 +1794,8 @@ static int libxl__build_device_model_a

Re: [Xen-devel] [PATCH v4 27/32] libxl: QEMU startup sync based on QMP

On Fri, Jul 27, 2018 at 03:06:09PM +0100, Anthony PERARD wrote:
> This is only activated when dm_restrict=1, as explained in the previous
> patch "libxl_dm: Pre-open QMP socket for QEMU"
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

Just one nit...

> ---
> 
> Notes:
> v4:
> moved to libxl__dm_spawn_* from libxl__spawn_*
> 
>  tools/libxl/libxl_dm.c   | 52 
>  tools/libxl/libxl_internal.h |  1 +
>  2 files changed, 53 insertions(+)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 9e3e501457..0c11e96a5d 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -2290,6 +2290,8 @@ static void device_model_startup_failed(libxl__egc *egc,
>  int rc);
>  static void device_model_detached(libxl__egc *egc,
>libxl__spawn_state *spawn);
> +static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
> +const libxl__json_object *response, int rc);
>  
>  /* our "next step" function, called from those callbacks and elsewhere */
>  static void device_model_spawn_outcome(libxl__egc *egc,
> @@ -2421,6 +2423,17 @@ retry_transaction:
>  spawn->failure_cb = device_model_startup_failed;
>  spawn->detached_cb = device_model_detached;
>  
> +libxl__ev_qmp_init(&dmss->qmp);
> +if (dm_monitor_fd >= 0) {
> +/* There is a valid QMP socket available now,
> + * use it to find out when QEMU is ready */
> +dmss->qmp.callback = device_model_qmp_cb;
> +dmss->qmp.domid = domid;
> +dmss->qmp.cfd = NULL;
> +rc = libxl__ev_qmp_send(gc, &dmss->qmp, "query-status", NULL);
> +if (rc) goto out_close;
> +}
> +
>  rc = libxl__spawn_spawn(egc, spawn);
>  if (rc < 0)
>  goto out_close;
> @@ -2490,6 +2503,43 @@ static void device_model_detached(libxl__egc *egc,
>  device_model_spawn_outcome(egc, dmss, 0);
>  }
>  
> +static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
> +const libxl__json_object *response,
> +int rc)
> +{
> +EGC_GC;
> +libxl__dm_spawn_state *dmss = CONTAINER_OF(ev, *dmss, qmp);
> +const libxl__json_object *o;
> +const char *status;
> +
> +libxl__ev_qmp_dispose(gc, ev);
> +
> +if (rc)
> +goto failed;
> +
> +o = libxl__json_map_get("status", response, JSON_STRING);
> +if (!o) {
> +LOGD(DEBUG, ev->domid, "QMP unexpected response");
> +rc = ERROR_FAIL;
> +goto failed;
> +}
> +status = libxl__json_object_get_string(o);
> +if (!strcmp(status, "running")) {
> +/* success */
> +} else {
> +LOGD(DEBUG, ev->domid, "Unexpected QEMU status: %s", status);
> +rc = ERROR_FAIL;
> +goto failed;
> +}

Isn't it clearer to just use:

if (strcmp(status, "running")) {
/* Failure. */
}

The empty success branch doesn't look very useful.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 28/32] libxl_qmp: Store advertised QEMU version in libxl__ev_qmp

On Fri, Jul 27, 2018 at 03:06:10PM +0100, Anthony PERARD wrote:
> This will be used in a later patch.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_internal.h |  7 +++
>  tools/libxl/libxl_qmp.c  | 16 
>  2 files changed, 23 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 01c3868748..4fa54cdb6a 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -432,6 +432,13 @@ struct libxl__ev_qmp {
>  libxl__ev_qmp_callback *callback;
>  libxl__carefd *cfd; /* set to send a fd with the command, NULL otherwise 
> */
>  
> +/* read-only when Connected */
> +struct {
> +int major;
> +int minor;
> +int micro;
> +} qemu_version;

I would init those field to some bogus value (-1) to make sure an use
before initialization will more likely cause a failure.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 29/32] libxl: Change libxl__domain_suspend_device_model() to be async.

On Fri, Jul 27, 2018 at 03:06:11PM +0100, Anthony PERARD wrote:
> This create an extra step for the two calls sites of the function.
^ call
> 
> Signed-off-by: Anthony PERARD 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization

2018-08-02 Thread Artem Mygaiev

Hello Julien

On 02.08.18 12:56, Julien Grall wrote:

Hi,

Sorry for the late posting. The notes were taken by Stefano Stabellini.
Thank you.

This has some clarifications requested from EPAM regarding PowerVR.

The existing graphics solutions on Xen today are:
- PV DRM:
* Supports multiple displays per VM
* Based on Grant-tables.
* Improvement of Xen FB which is based on foreign mapping

Frontend driver will be part of LK starting 4.18
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7

- Intel GVT: https://01.org/igvt-g
* Based on IOREQ server infrastructure
* Performance is 70% of direct assigned hardware

- NVIDIA:
* Much more virtualizable
* Provide mappable chunk of PCI BARs.
* Userspace component emulates PCI config space

Current effort for graphic virtualization on Arm:
- Samsung: They have a PV OpenGL solution. This seems to be fast.

This is interesting. Do you know if there is any open benchmark data?

- EPAM:
* PV OpenGL was dismissed because of performance concern
* PV DRM for sharing display
* PowerVR native virtualization (see below)

PoverVR virtualization:

Recent PoverVR hardware provided some virtualization support. The
solution is implemented in the firmware. A kernel module is used to talk
to the firmware via shared memory. The toolstack only have to setup
memory context for each VM.

** Recent PoverVR HW has some virtualization support
** Kernel module

It was not clear whether an extra pair of frontend/backend was required
along with the PowerVR driver.

@Action: EPAM, could you clarify it?

No, there are no extra FE/BE drivers for GPU sharing in case of PowerVR.

Potential solution for upstream:
- PV OpenGL
- vGPU solution outside of the hypervisor (see below)

vGPU solution outside of the hypervisor:

A unikernel (or Dom0) based environment could be provided to run
proprietary software. >

One more option we we were discussing is "de-priviledged" or "native
applications in Xen:

https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01002.html
We are looking into unikernels, too.

The proprietary software would use IOREQ server infrastructure to
emulate guest memory region used by the GPU and do the scheduling
decisions.

We also had an RFC for co-processors (including GPU) management some
time ago:

https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html

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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization



On 02/08/2018, 16:27, "Artem Mygaiev"  wrote:

Hello Julien

On 02.08.18 12:56, Julien Grall wrote:
> Hi,
> 
> Sorry for the late posting. The notes were taken by Stefano Stabellini. 
> Thank you.
> 
> This has some clarifications requested from EPAM regarding PowerVR.
> 
> The existing graphics solutions on Xen today are:
> - PV DRM:
>  * Supports multiple displays per VM
>  * Based on Grant-tables.
>  * Improvement of Xen FB which is based on foreign mapping
> 
Frontend driver will be part of LK starting 4.18

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7

> - Intel GVT: https://01.org/igvt-g
>  * Based on IOREQ server infrastructure
>  * Performance is 70% of direct assigned hardware
> 
> - NVIDIA:
>  * Much more virtualizable
>  * Provide mappable chunk of PCI BARs.
>  * Userspace component emulates PCI config space
> 
> Current effort for graphic virtualization on Arm:
> - Samsung: They have a PV OpenGL solution. This seems to be fast.

This is interesting. Do you know if there is any open benchmark data?

The presentation and recording is at
https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics
https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7
  
Lars


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

Re: [Xen-devel] [PATCH v4 30/32] libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp

On Fri, Jul 27, 2018 at 03:06:12PM +0100, Anthony PERARD wrote:
> +static void dm_stopped(libxl__egc *egc, libxl__ev_qmp *ev,
> +   const libxl__json_object *response, int rc)
> +{
> +EGC_GC;
> +libxl__domain_suspend_state *dsps = CONTAINER_OF(ev, *dsps, qmp);
> +const char *const filename = dsps->dm_savefile;
> +uint32_t const domid = ev->domid;
> +
> +if (rc)
> +goto out;
> +
> +libxl__carefd_begin();
> +ev->cfd = libxl__carefd_opened(CTX,
> + open(filename, O_WRONLY | O_CREAT, 0600));
> +if (!ev->cfd) {
> +LOGED(ERROR, domid, "Failed to open file %s for QEMU", filename);
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +
> +ev->callback = dm_state_fd_ready;
> +rc = libxl__ev_qmp_send(gc, ev, "add-fd", NULL);
> +if (rc)
> +goto out;
> +
> +return;
> +out:

That label would be better named 'error', because it's only used for
the error paths.

> +if (ev->cfd) {
> +libxl__carefd_close(ev->cfd);
> +unlink(filename);
> +ev->cfd = NULL;
> +}
> +dsps->callback_device_model_done(egc, dsps, rc);
> +}
> +
> +static void dm_state_fd_ready(libxl__egc *egc, libxl__ev_qmp *ev,
> +  const libxl__json_object *response, int rc)
> +{
> +EGC_GC;
> +libxl__domain_suspend_state *dsps = CONTAINER_OF(ev, *dsps, qmp);
> +libxl__json_object *args = NULL;
> +const libxl__json_object *o;
> +int fdset;
> +
> +libxl__carefd_close(ev->cfd);
> +ev->cfd = NULL;
> +
> +if (rc)
> +goto out;
> +
> +o = libxl__json_map_get("fdset-id", response, JSON_INTEGER);
> +if (!o) {
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +fdset = libxl__json_object_get_integer(o);
> +
> +ev->callback = dm_state_saved;
> +
> +if (qmp_ev_qemu_check_version(ev, 2, 11, 0))
> +qmp_parameters_add_bool(gc, &args, "live", dsps->live);
> +QMP_PARAMETERS_SPRINTF(&args, "filename", "/dev/fdset/%d", fdset);
> +rc = libxl__ev_qmp_send(gc, ev, "xen-save-devices-state", args);

I think some comments about the logic above would be helpful (at least
for me). Do you need to pass an extra argument to 2.11.0 and higher
versions in order to live-migrate?

> +if (rc)
> +goto out;
> +
> +return;
> +out:

Same here regarding the naming of the label.

> +if (rc)
> +unlink(dsps->dm_savefile);
> +dsps->callback_device_model_done(egc, dsps, rc);
> +}
> +
> +static void dm_state_saved(libxl__egc *egc, libxl__ev_qmp *ev,
> +   const libxl__json_object *response, int rc)
> +{
> +EGC_GC;
> +libxl__domain_suspend_state *dsps = CONTAINER_OF(ev, *dsps, qmp);
> +
> +if (rc)
> +unlink(dsps->dm_savefile);

Use the libxl unlink helper.

Thanks, Roger.

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

Re: [Xen-devel] [RFC] OVMF on PVH

On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> Hi,
> 
> I've been working on booting OVMF in a PVH guest. There are few changes
> that I'd like your comments on. Those are changes that I've already made
> in my private branch, there are either required or will make things
> easier.
> 
> ## Goal
> 
> Have a single blob that can be use for both HVM and PVH guests. And be
> able to start UEFI compatible guests in PVH.
> 
> 
> ## New binary, separated from QEMU/KVM one.
> 
> Right now, the rules to build the firmware are located in
> `OvmfPkg/OvmfPkgX64.dsc`, a platform. I've created a new platform, without
> KVM support, and would like to retire the Xen support from the current
> platform.  For now, I have created OvmfPkg/XenOvmf.dsc. (The change to a
> new platform had been proposed by upstream.)
> 
> That would simplify Xen support in OVMF, and allow to diverge more from
> OVMF where needed. That would mostly be useful during the initial boot
> phase where there lots of `if xen do that, else do that`.
> 
> We can also choose some drivers that can work on both PVH and HVM, for
> example, use a LAPIC timer instead of ACPI Timer.
> 
> All this mean that building OVMF for Xen would need to be change.

Changing things in xen.git is easy and fine. This is more about
introducing a burden for downstream packagers because they need to build
a separate packages.

This is not saying I'm against this idea in any way, just something that
comes to my mind.

> 
> 
> ## ELF header
> 
> Adding an ELF header to OVMF so the blob can be loaded by libxl/libxc
> without modifying those libs.
> 
> That replace a section of the OVMF binary called VarStore by that ELF
> header.  It's empty and libxl doesn't know how to use it. (QEMU/KVM would
> have a flash device loading the store, so it can be written to.)

But long term we might want to support VarStore (that is used to stored
config, right?). How are we going to do that in the future if we
repurpose it now?

> 
> With the ELF header, I can test OVMF by simply adding this in the config
> file:
> 
> type='pvh'
> kernel='/path/to/OVMF.fd'
> 
> We could use a modified `hvmloader` to load OVMF on PVH or teach libxc to
> load it at a hardcoded location, but I don't see it as necessary, and if
> we have one less firmware to load, it's probably better.
> 
> With the use of an ELF header comes another issue, which as to do with
> were the binary needs to be loaded initially.
> 
> ## Loading binary at 0x1 (1MB, like hvmloader on HVM)
> 
> Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with
> hvmloader moving some RAM around to allow that.  But with the use of an
> ELF header, and let libxc load the blob, it was not possible to load the
> blob just below 4GB. (Or at least without modification of the toolstack I
> guess.) So I've attempted to have OVMF been started from a different place
> in memory. Then I had to hack a bit more in order to be able to start OVMF
> from two different location (the current one for HVM guest, and a new one
> that can be used for PVH). That works fine, I'll just have to find out
> what upstream think about that.

If you specify the virt_addr (?) in the ELF header, libxc should know
how to deal with that? What is missing in the current toolstack code?

Wei.

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

Re: [Xen-devel] [PATCH v4 31/32] libxl_disk: Cut libxl_cdrom_insert into step

On Fri, Jul 27, 2018 at 03:06:13PM +0100, Anthony PERARD wrote:
> This is to prepare libxl_cdrom_insert to be able to send commands to
> QEMU via the libxl__ev_qmp. The next patch is going to make use of it.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_disk.c | 194 +++
>  1 file changed, 137 insertions(+), 57 deletions(-)
> 
> diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
> index e9eceb65e3..c759179628 100644
> --- a/tools/libxl/libxl_disk.c
> +++ b/tools/libxl/libxl_disk.c
> @@ -661,31 +661,55 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t 
> domid,
>  return rc;
>  }
>  
> +typedef struct {
> +libxl__ao *ao;
> +libxl_domain_config d_config;
> +const char *be_path;
> +const char *libxl_path;
> +libxl_device_disk *disk;
> +libxl_device_disk disk_empty;
> +libxl_device_disk disk_saved;
> +int dm_ver;
> +int domid;
> +libxl__domain_userdata_lock *lock;
> +} libxl__cdrom_insert_state;
> +static void cdrom_insert_ejected(libxl__egc *egc,
> + libxl__cdrom_insert_state *cis);
> +static void cdrom_insert_inserted(libxl__egc *egc,
> +  libxl__cdrom_insert_state *cis);
> +static void cdrom_insert_done(libxl__egc *egc,
> +  libxl__cdrom_insert_state *cis,
> +  int rc);

Can you provide a comment explaining how is this supposed to work? The
current code is already quite convoluted IMO (maybe because I'm not
familiar with it), so I think a comment would help reviewers.

Thanks, Roger.

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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization

2018-08-02 Thread Artem Mygaiev


Hi Lars

On 02.08.18 18:29, Lars Kurth wrote:



On 02/08/2018, 16:27, "Artem Mygaiev"  wrote:

 Hello Julien
 
 On 02.08.18 12:56, Julien Grall wrote:

 > Hi,
 >
 > Sorry for the late posting. The notes were taken by Stefano Stabellini.
 > Thank you.
 >
 > This has some clarifications requested from EPAM regarding PowerVR.
 >
 > The existing graphics solutions on Xen today are:
 > - PV DRM:
 >  * Supports multiple displays per VM
 >  * Based on Grant-tables.
 >  * Improvement of Xen FB which is based on foreign mapping
 >
 Frontend driver will be part of LK starting 4.18
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7
 
 > - Intel GVT: https://01.org/igvt-g

 >  * Based on IOREQ server infrastructure
 >  * Performance is 70% of direct assigned hardware
 >
 > - NVIDIA:
 >  * Much more virtualizable
 >  * Provide mappable chunk of PCI BARs.
 >  * Userspace component emulates PCI config space
 >
 > Current effort for graphic virtualization on Arm:
 > - Samsung: They have a PV OpenGL solution. This seems to be fast.
 
 This is interesting. Do you know if there is any open benchmark data?


The presentation and recording is at
https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics
https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7
   


Thanks for pointing to XDS materials. Unfortunately, there is no 
comparison with "native" GPU performance (non-virtualized)... I guess I 
need to ask Samsung folks for details.


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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization


Hi Artem,

On 02/08/18 16:54, Artem Mygaiev wrote:

On 02.08.18 18:29, Lars Kurth wrote:



On 02/08/2018, 16:27, "Artem Mygaiev"  wrote:

 Hello Julien
 On 02.08.18 12:56, Julien Grall wrote:
 > Hi,
 >
 > Sorry for the late posting. The notes were taken by Stefano 
Stabellini.

 > Thank you.
 >
 > This has some clarifications requested from EPAM regarding 
PowerVR.

 >
 > The existing graphics solutions on Xen today are:
 > - PV DRM:
 >  * Supports multiple displays per VM
 >  * Based on Grant-tables.
 >  * Improvement of Xen FB which is based on foreign mapping
 >
 Frontend driver will be part of LK starting 4.18
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7 


 > - Intel GVT: https://01.org/igvt-g
 >  * Based on IOREQ server infrastructure
 >  * Performance is 70% of direct assigned hardware
 >
 > - NVIDIA:
 >  * Much more virtualizable
 >  * Provide mappable chunk of PCI BARs.
 >  * Userspace component emulates PCI config space
 >
 > Current effort for graphic virtualization on Arm:
 > - Samsung: They have a PV OpenGL solution. This seems to be 
fast.
 This is interesting. Do you know if there is any open benchmark 
data?


The presentation and recording is at
https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics 

https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7 



Thanks for pointing to XDS materials. Unfortunately, there is no 
comparison with "native" GPU performance (non-virtualized)... I guess I 
need to ask Samsung folks for details.
They do compare with Dom0 (slides 20 and onwards). Dom0 has the direct 
access to the GPU, so this is very similar to native.


Did you expect other comparison?

Cheers,


--
Julien Grall

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

[Xen-devel] [qemu-mainline test] 125732: trouble: blocked/broken/fail/pass

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

Failures and problems with tests :-(

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

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

version targeted for testing:
 qemuuf7502360397d291be04bc040e9f96c92ff2d8030
baseline version:
 qemuu18a398f6a39df4b08ff86ac0d38384193ca5f4cc

Last test of basis   125640  2018-07-27 22:16:44 Z5 days
Failing since125675  2018-07-30 09:36:58 Z3 days3 attempts
Testing same since   125732  2018-08-01 11:30:00 Z1 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Christian Borntraeger 
  Cornelia Huck 
  Dr. David Alan Gilbert 
  Fam Zheng 
  Geert Uytterhoeven 
  Jay Zhou 
  Kevin Wolf 
  KONRAD Frederic 
  Laurent Vivier 
  Leonid Bloch 
  liujunjie 
  Marc-André Lureau 
  Markus Armbruster 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Richard Henderson 
  Shivaprasad G Bhat 
  Thomas Huth 

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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization

2018-08-02 Thread Artem Mygaiev




On 02.08.18 18:57, Julien Grall wrote:

Hi Artem,

On 02/08/18 16:54, Artem Mygaiev wrote:

On 02.08.18 18:29, Lars Kurth wrote:



On 02/08/2018, 16:27, "Artem Mygaiev"  wrote:

 Hello Julien
 On 02.08.18 12:56, Julien Grall wrote:
 > Hi,
 >
 > Sorry for the late posting. The notes were taken by Stefano 
Stabellini.

 > Thank you.
 >
 > This has some clarifications requested from EPAM regarding 
PowerVR.

 >
 > The existing graphics solutions on Xen today are:
 > - PV DRM:
 >  * Supports multiple displays per VM
 >  * Based on Grant-tables.
 >  * Improvement of Xen FB which is based on foreign 
mapping

 >
 Frontend driver will be part of LK starting 4.18
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7 


 > - Intel GVT: https://01.org/igvt-g
 >  * Based on IOREQ server infrastructure
 >  * Performance is 70% of direct assigned hardware
 >
 > - NVIDIA:
 >  * Much more virtualizable
 >  * Provide mappable chunk of PCI BARs.
 >  * Userspace component emulates PCI config space
 >
 > Current effort for graphic virtualization on Arm:
 > - Samsung: They have a PV OpenGL solution. This seems to 
be fast.
 This is interesting. Do you know if there is any open benchmark 
data?


The presentation and recording is at
https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics 

https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7 



Thanks for pointing to XDS materials. Unfortunately, there is no 
comparison with "native" GPU performance (non-virtualized)... I guess 
I need to ask Samsung folks for details.
They do compare with Dom0 (slides 20 and onwards). Dom0 has the direct 
access to the GPU, so this is very similar to native.


Did you expect other comparison?


Yes, implementation of sharing may impact Dom0 performance. In this case 
it seems that native GL applications in Dom0 are also reside in SVDM 
somehow (slide 14). I am not saying it is necessary impacting, but it is 
always better to have non-virtualized environment as a reference.


Too bad I couldn't make it to XDS due to conflict with AGL/OSS events :(

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

Re: [Xen-devel] [RFC] OVMF on PVH

On Thu, Aug 02, 2018 at 12:24:35PM +0100, Anthony PERARD wrote:
> Hi,
> 
> I've been working on booting OVMF in a PVH guest. There are few changes
> that I'd like your comments on. Those are changes that I've already made
> in my private branch, there are either required or will make things
> easier.
> 
> ## Goal
> 
> Have a single blob that can be use for both HVM and PVH guests. And be
> able to start UEFI compatible guests in PVH.
> 
> 
> ## New binary, separated from QEMU/KVM one.
> 
> Right now, the rules to build the firmware are located in
> `OvmfPkg/OvmfPkgX64.dsc`, a platform. I've created a new platform, without
> KVM support, and would like to retire the Xen support from the current
> platform.  For now, I have created OvmfPkg/XenOvmf.dsc. (The change to a
> new platform had been proposed by upstream.)

Is it my understanding that after this there will be a generic
platform (for QEMU, KVM and everything else) and a platform for Xen?

> That would simplify Xen support in OVMF, and allow to diverge more from
> OVMF where needed. That would mostly be useful during the initial boot
> phase where there lots of `if xen do that, else do that`.

I fear this might be dangerous because most developers will only test
against the generic platform, so breakage could be introduced more
easily to the Xen platform without upstream noticing?

> We can also choose some drivers that can work on both PVH and HVM, for
> example, use a LAPIC timer instead of ACPI Timer.
> 
> All this mean that building OVMF for Xen would need to be change.

And distros will likely have to provide two different packages, or a
single package with the generic binary and the Xen specific one.

> 
> ## ELF header
> 
> Adding an ELF header to OVMF so the blob can be loaded by libxl/libxc
> without modifying those libs.
> 
> That replace a section of the OVMF binary called VarStore by that ELF
> header.  It's empty and libxl doesn't know how to use it. (QEMU/KVM would
> have a flash device loading the store, so it can be written to.)

Can't you just add the header without replacing anything? The ELF
header is quite small, so I don't think size should be a problem (if
that's why it's placed on top of the VarStore).

> With the ELF header, I can test OVMF by simply adding this in the config
> file:
> 
> type='pvh'
> kernel='/path/to/OVMF.fd'

Yes, that's the expectation and is what firmware='ovmf|uefi' should
do behind the scenes.

> We could use a modified `hvmloader` to load OVMF on PVH or teach libxc to
> load it at a hardcoded location, but I don't see it as necessary, and if
> we have one less firmware to load, it's probably better.
> 
> With the use of an ELF header comes another issue, which as to do with
> were the binary needs to be loaded initially.
> 
> ## Loading binary at 0x1 (1MB, like hvmloader on HVM)

That works well for hvmloader because after it has finished running
the memory can be overwritten without issues. The same is not true for
ovmf which needs to keep data around so that boot services and runtime
services can continue working.

> Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with
> hvmloader moving some RAM around to allow that.  But with the use of an
> ELF header, and let libxc load the blob, it was not possible to load the
> blob just below 4GB. (Or at least without modification of the toolstack I
> guess.)

libxc/libelf will load the binary in the position specified by the ELF
program headers PhysAddr field (also called LMA). If you execute
`readelf -l ` you should see the program headers and the
address where they should be loaded.

You can easily modify the LMA in the linker script using the AT
keyword.

> So I've attempted to have OVMF been started from a different place
> in memory. Then I had to hack a bit more in order to be able to start OVMF
> from two different location (the current one for HVM guest, and a new one
> that can be used for PVH). That works fine, I'll just have to find out
> what upstream think about that.

I think the address where ovmf is loaded should be the same for HVM or
PVH if possible. We know that loading at this address works for HVM,
so I think we should keep it for PVH, it's less likely to cause issues
in the future if both are kept in sync.

Thanks, Roger.

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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Graphic virtualization

2018-08-02 Thread Stefano Stabellini

On Thu, 2 Aug 2018, Artem Mygaiev wrote:
> On 02.08.18 18:57, Julien Grall wrote:
> > Hi Artem,
> > 
> > On 02/08/18 16:54, Artem Mygaiev wrote:
> > > On 02.08.18 18:29, Lars Kurth wrote:
> > > > 
> > > > 
> > > > On 02/08/2018, 16:27, "Artem Mygaiev"  wrote:
> > > > 
> > > >  Hello Julien
> > > >  On 02.08.18 12:56, Julien Grall wrote:
> > > >  > Hi,
> > > >  >
> > > >  > Sorry for the late posting. The notes were taken by Stefano
> > > > Stabellini.
> > > >  > Thank you.
> > > >  >
> > > >  > This has some clarifications requested from EPAM regarding
> > > > PowerVR.
> > > >  >
> > > >  > The existing graphics solutions on Xen today are:
> > > >  > - PV DRM:
> > > >  >  * Supports multiple displays per VM
> > > >  >  * Based on Grant-tables.
> > > >  >  * Improvement of Xen FB which is based on foreign
> > > > mapping
> > > >  >
> > > >  Frontend driver will be part of LK starting 4.18
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7
> > > >  
> > > >  > - Intel GVT: https://01.org/igvt-g
> > > >  >  * Based on IOREQ server infrastructure
> > > >  >  * Performance is 70% of direct assigned hardware
> > > >  >
> > > >  > - NVIDIA:
> > > >  >  * Much more virtualizable
> > > >  >  * Provide mappable chunk of PCI BARs.
> > > >  >  * Userspace component emulates PCI config space
> > > >  >
> > > >  > Current effort for graphic virtualization on Arm:
> > > >  > - Samsung: They have a PV OpenGL solution. This seems to be
> > > > fast.
> > > >  This is interesting. Do you know if there is any open benchmark
> > > > data?
> > > > 
> > > > The presentation and recording is at
> > > > https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics
> > > >  
> > > > https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7
> > > >  
> > > 
> > > Thanks for pointing to XDS materials. Unfortunately, there is no
> > > comparison with "native" GPU performance (non-virtualized)... I guess I
> > > need to ask Samsung folks for details.
> > They do compare with Dom0 (slides 20 and onwards). Dom0 has the direct
> > access to the GPU, so this is very similar to native.
> > 
> > Did you expect other comparison?
> 
> Yes, implementation of sharing may impact Dom0 performance. In this case it
> seems that native GL applications in Dom0 are also reside in SVDM somehow
> (slide 14). I am not saying it is necessary impacting, but it is always better
> to have non-virtualized environment as a reference.
> 
> Too bad I couldn't make it to XDS due to conflict with AGL/OSS events :(

I took his business card, I'll try to make introductions.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Routing physical interrupts to EL1

2018-08-02 Thread Saeed Mirzamohammadi

Sorry for the late reply.

On Sat, Jul 7, 2018 at 2:25 PM, Julien Grall  wrote:

> Hello,
>
> On 07/07/2018 08:32 PM, Saeed Mirzamohammadi wrote:
>
>> Thanks for your detailed reply.
>>
>> On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall > > wrote:
>>
>>
>>
>> On 06/07/18 04:51, Saeed Mirzamohammadi wrote:
>>
>> Hi,
>>
>>
>> Hello,
>>
>> I'm trying to route all the physical interrupts to the guest
>> domain rather than being trapped in the Xen. I would like to
>> know what is the right way to do that?
>>
>>
>> May I ask what is your use case for that? If you route interrupts to
>> the guest, Xen will not receive vital interrupt such as the timer,
>> UART, SMMU interrupts, maintenance interrupt
>>
>> I only have one guest domain. So, I'm trying to make Xen transparent to
>> avoid any extra overhead caused by trapping interrupts.
>>
>
> Do you include Dom0 in your "one guest domain"? If so, may I ask what is
> your end goal? Why not booting the OS on baremetal?
>
> Yes, I only have the Dom0 domain and no DomU. My end goal is to make Xen
transparent to the interrupts but have control over the memory management
and be able to create another domain (like a driver domain) on-demand
whenever I need it.


> But I still need Xen for my own hypercalls. I don't need the timer cause I
>> pinned and don't need any vcpu scheduler.
>>
>
> Well, Xen still needs interrupts for other things like UART and SMMU. It
> also needs interrupts to IPI other pCPU such as for softirq, unblocking
> another vCPU (waiting on an event for instance)... I don't think you can
> discard interrupts that easily in Xen without some cooperation with the
> guest.
>
> Let's imagine Xen IPIs another pCPU. If interrupts are routed to your
> guest, this guest will receive the IPIs and will not understand what to do.

My end goal is that all the IPIs are handled in the guest like when it is
on baremetal.


>
>
> Based on my understanding, I can only disable the interrupts on ARM all
>> together using the HCR_EL2 register and we can't pick one interrupt to not
>> trap, right?
>>
>
> Depends on your interrupts controller. On GICv4, you will be able to
> directly injected some LPIs (i.e MSI).
>
>
>
>>
>>
>> I know that HCR_IMO bit in the HCR_EL2 register is supposed to
>> be for routing the interrupts to the guest (Routing to EL1
>> instead of EL2).
>> link to the datasheet:
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.
>> ddi0500d/CIHJHAAG.html
>> > .ddi0500d/CIHJHAAG.html>
>>
>> So, I have tried doing the following in
>> the leave_hypervisor_tail. I run a simple hypercall and do the
>> following lines before return (which is I guess the last point
>> of exit to the guest from hypervisor):
>> -
>> /current->arch.hcr_el2 &= ~HCR_IMO;/
>> /WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);/
>> /isb();/
>> /--/
>> /
>> /
>> /It looks like to be doing it right for all
>> thevcpus butgets stuck after return from leave_hypervisor_tail
>> for the lastvcpu.
>>
>>
>> What do you mean by stuck? Do you see any logs?
>>
>> It's hung with no log.
>>
>>
>> HCR_EL2.IMO unset means the interrupt will get signaled to EL1. It
>> does not affect how interrupt will get read (e.g IAR).
>>
>> Which interrupt controller are you using?
>>
>> I'm using a GICv2.
>>
>> In case of GICv2, Xen is re-mapping GICC to GICV. So when the guest
>> is reading IAR, it will read the interrupts from the LRs. Not the
>> physical interface.
>>
>>   So, in the case of GICv2, we can't route them cause Xen is the one that
>> is updating the LRs and guest is reading from the LRs, am I right?
>>
>
> If you want to route *all* the interrupts, you can map GICC and not GICV
> to your guest. So when the guest will read IAR, it will read the physical
> interrupts.
>
>
>>
>> In case of GICv3, HCR_EL2.IMO will also control the access. So you
>> should be fine here.
>>
>> However, in both case you will at least need to rework the way
>> software generated interrupts are sent to the guest. At the moment,
>> they are written in the LRs.
>>
>> Is it possible to not trap on the ICDSGIR (SGI register)?
>>
>
> SGIs register are already trapped by Xen. They are emulated by writing the
> corresponding interrupt to the LRs.
>
> How can make it available to the guest and not trap in Xen? Is it doable?


> However, SGIs are not the only interrupt generated by the hypervisor
> directly. There are also the event channel (a PPI) or any device emulated
> by the hypervisor (e.g PL011).
>
> Trying to remove interrupts from the hypervisor is more a pain compare to
> the benefits you will gain. You will be better at improving the

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

2018-08-02 Thread Srivatsa S. Bhat

On 7/26/18 4:09 PM, Kees Cook wrote:
> On Tue, Jul 24, 2018 at 3:02 PM, Jiri Kosina  wrote:
>> On Tue, 24 Jul 2018, Srivatsa S. Bhat wrote:
>>
>>> However, if you are proposing that you'd like to contribute the enhanced
>>> PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and
>>> have them merged instead of this patch series, then I would certainly
>>> welcome it!
>>
>> I'd in principle love us to push everything back to 4.4, but there are a
>> few reasons (*) why that's not happening shortly.
>>
>> Anyway, to point out explicitly what's really needed for those folks
>> running 4.4-stable and relying on PTI providing The Real Thing(TM), it's
>> either a 4.4-stable port of
>>
>> 
>> http://kernel.suse.com/cgit/kernel-source/plain/patches.suse/x86-entry-64-use-a-per-cpu-trampoline-stack.patch?id=3428a77b02b1ba03e45d8fc352ec350429f57fc7
>>
>> or making THREADINFO_GFP imply __GFP_ZERO.
> 
> This is true in Linus's tree now. Should be trivial to backport:
> https://git.kernel.org/linus/e01e80634ecdd
> 

Hi Jiri, Kees,

Thank you for suggesting the patch! I have attached the (locally
tested) 4.4 and 4.9 backports of that patch with this mail. (The
mainline commit applies cleanly on 4.14).

Greg, could you please consider including them in stable 4.4, 4.9
and 4.14?

Thank you very much!

Regards,
Srivatsa
VMware Photon OS
From 7e39d8ccbb0889c03ce6dc0dee0e63d78f37d0a9 Mon Sep 17 00:00:00 2001
From: Kees Cook 
Date: Fri, 20 Apr 2018 14:55:31 -0700
Subject: [PATCH] fork: unconditionally clear stack on fork

commit e01e80634ecdde1dd113ac43b3adad21b47f3957 upstream.

One of the classes of kernel stack content leaks[1] is exposing the
contents of prior heap or stack contents when a new process stack is
allocated.  Normally, those stacks are not zeroed, and the old contents
remain in place.  In the face of stack content exposure flaws, those
contents can leak to userspace.

Fixing this will make the kernel no longer vulnerable to these flaws, as
the stack will be wiped each time a stack is assigned to a new process.
There's not a meaningful change in runtime performance; it almost looks
like it provides a benefit.

Performing back-to-back kernel builds before:
Run times: 157.86 157.09 158.90 160.94 160.80
Mean: 159.12
Std Dev: 1.54

and after:
Run times: 159.31 157.34 156.71 158.15 160.81
Mean: 158.46
Std Dev: 1.46

Instead of making this a build or runtime config, Andy Lutomirski
recommended this just be enabled by default.

[1] A noisy search for many kinds of stack content leaks can be seen here:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel+stack+leak

I did some more with perf and cycle counts on running 100,000 execs of
/bin/true.

before:
Cycles: 218858861551 218853036130 214727610969 227656844122 224980542841
Mean:  221015379122.60
Std Dev: 4662486552.47

after:
Cycles: 213868945060 213119275204 211820169456 224426673259 225489986348
Mean:  217745009865.40
Std Dev: 5935559279.99

It continues to look like it's faster, though the deviation is rather
wide, but I'm not sure what I could do that would be less noisy.  I'm
open to ideas!

Link: http://lkml.kernel.org/r/20180221021659.GA37073@beast
Signed-off-by: Kees Cook 
Acked-by: Michal Hocko 
Reviewed-by: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Laura Abbott 
Cc: Rasmus Villemoes 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[ Srivatsa: Backported to 4.4.y ]
Signed-off-by: Srivatsa S. Bhat 
Reviewed-by: Srinidhi Rao 
---
 include/linux/thread_info.h | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index ff307b5..646891f 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -55,11 +55,7 @@ extern long do_no_restart_syscall(struct restart_block 
*parm);

 #ifdef __KERNEL__

-#ifdef CONFIG_DEBUG_STACK_USAGE
-# define THREADINFO_GFP(GFP_KERNEL | __GFP_NOTRACK | 
__GFP_ZERO)
-#else
-# define THREADINFO_GFP(GFP_KERNEL | __GFP_NOTRACK)
-#endif
+#define THREADINFO_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO)

 /*
  * flag set/clear/test wrappers
-- 
2.7.4

From 7debcc6438b4a0bdc9a7b509a751350dad883328 Mon Sep 17 00:00:00 2001
From: Kees Cook 
Date: Fri, 20 Apr 2018 14:55:31 -0700
Subject: [PATCH] fork: unconditionally clear stack on fork

commit e01e80634ecdde1dd113ac43b3adad21b47f3957 upstream.

One of the classes of kernel stack content leaks[1] is exposing the
contents of prior heap or stack contents when a new process stack is
allocated.  Normally, those stacks are not zeroed, and the old contents
remain in place.  In the face of stack content exposure flaws, those
contents can leak to userspace.

Fixing this will make the kernel no longer vulnerable to these flaws, as
the stack will be wiped each time a stack is assigned to a new process.
There's not a meaningful change in runtime performance; it al

Re: [Xen-devel] Routing physical interrupts to EL1

Hello,

Please configure your e-mail client to quote properly (i.e with >).

On 02/08/2018 20:14, Saeed Mirzamohammadi wrote:

Sorry for the late reply.

On Sat, Jul 7, 2018 at 2:25 PM, Julien Grall > wrote:

Hello,

On 07/07/2018 08:32 PM, Saeed Mirzamohammadi wrote:

Thanks for your detailed reply.

On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall
mailto:julien.gr...@arm.com>
>> wrote:

     On 06/07/18 04:51, Saeed Mirzamohammadi wrote:

         Hi,

     Hello,

         I'm trying to route all the physical interrupts to the
guest
         domain rather than being trapped in the Xen. I would
like to
         know what is the right way to do that?

     May I ask what is your use case for that? If you route
interrupts to
     the guest, Xen will not receive vital interrupt such as the
timer,
     UART, SMMU interrupts, maintenance interrupt

I only have one guest domain. So, I'm trying to make Xen
transparent to avoid any extra overhead caused by trapping
interrupts.

Do you include Dom0 in your "one guest domain"? If so, may I ask
what is your end goal? Why not booting the OS on baremetal?

Yes, I only have the Dom0 domain and no DomU. My end goal is to make Xen 
transparent to the interrupts but have control over the memory 
management and be able to create another domain (like a driver domain) 
on-demand whenever I need it.

Then you really don't want bypass Xen for the interrupts... If you do 
that, you will lose the ability to communicate between physical CPUs in 
the hypervisor.

But I still need Xen for my own hypercalls. I don't need the
timer cause I pinned and don't need any vcpu scheduler.

Well, Xen still needs interrupts for other things like UART and
SMMU. It also needs interrupts to IPI other pCPU such as for
softirq, unblocking another vCPU (waiting on an event for
instance)... I don't think you can discard interrupts that easily in
Xen without some cooperation with the guest.

Let's imagine Xen IPIs another pCPU. If interrupts are routed to
your guest, this guest will receive the IPIs and will not understand
what to do.

My end goal is that all the IPIs are handled in the guest like when it 
is on baremetal.

You keep saying interrupts should be directly routed to the guest but 
you don't explain why you want that. As I said in my previous e-mail,

trying to remove interrupts from the hypervisor is more a pain
compare to the benefits you will gain. You will be better at
improving the latency when receiving interrupt (AFAIK this is
already be good).

Based on my understanding, I can only disable the interrupts on
ARM all together using the HCR_EL2 register and we can't pick
one interrupt to not trap, right?

Depends on your interrupts controller. On GICv4, you will be able to
directly injected some LPIs (i.e MSI).

         I know that HCR_IMO bit in the HCR_EL2 register is
supposed to
         be for routing the interrupts to the guest (Routing to EL1
         instead of EL2).
         link to the datasheet:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500d/CIHJHAAG.html

>

         So, I have tried doing the following in
         the leave_hypervisor_tail. I run a simple hypercall and
do the
         following lines before return (which is I guess the
last point
         of exit to the guest from hypervisor):
         -
         /current->arch.hcr_el2 &= ~HCR_IMO;/
         /WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);/
         /isb();/
         /--/
         /
         /
         /It looks like to be doing it right for all
         thevcpus butgets stuck after return from
leave_hypervisor_tail
         for the lastvcpu.

     What do you mean by stuck? Do you see any logs?

It's hung with no log.

     HCR_EL2.IMO unset means the interrupt will get signaled to
EL1. It
     does not affect how interrupt will get read (e.g IAR).

     Which interrupt controller are you using?

I'm using a GICv2.

     In case of GICv2, Xen is re-mapping GICC to GICV. So when
the guest
     is reading IAR, it will read the interrupt

Re: [Xen-devel] [PATCH v8 00/11] arm: more kconfig configurability and small default configs

2018-08-02 Thread Stefano Stabellini

On Thu, 2 Aug 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 31/07/18 17:10, Stefano Stabellini wrote:
> > On Tue, 31 Jul 2018, Julien Grall wrote:
> > > On 30/07/18 18:48, Stefano Stabellini wrote:
> > > > Hi all,
> > > 
> > > Hi Stefano,
> > > 
> > > > 
> > > > This patch series is the first step toward building a small certifiable
> > > > Xen hypervisor for ARM boards.
> > > > 
> > > > The series makes a few changes to allow disabling more kconfig options:
> > > > most of them already exist but cannot be disabled. It also introduces a
> > > > reference kconfig for Renesas RCar (due to popular demand, candidate for
> > > > certifications), Xilinx MPSoC, and for QEMU aarch64 (not for
> > > > certifications, but useful for debugging).
> > > > 
> > > > The last patch clarifies the security support status of kconfig options
> > > > in Xen.
> > > > 
> > > > All patches are already acked, except for patch #8: "arm: add ALL_PLAT,
> > > > QEMU, Rcar3 and MPSoC configs".
> > > > 
> > > > Cheers,
> > > > 
> > > > Stefano
> > > > 
> > > > 
> > > > The following changes since commit
> > > > 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5:
> > > > 
> > > > docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again
> > > > (2018-04-13 17:04:36 +0100)
> > > 
> > > This is nearly 4 months old... Please resend the series rebased on the
> > > latest
> > > staging.
> > 
> > This is the rebase on staging, let me know if you would also like me to
> > send it to the list. This branch is exactly identical to v8 (aside from
> > the first patch being dropped): I haven't done Jan's small request for
> > change. Let me know if you prefer that I do.
> 
> I addressed Jan's small request and committed.

Thank you!

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

Re: [Xen-devel] [PATCH v6 1/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

2018-08-02 Thread Stefano Stabellini

On Thu, 2 Aug 2018, Jan Beulich wrote:
> >> > +/*
> >> > + * This action also requires that @current targets @d, but it has 
> >> > already been
> >> > + * checked somewhere higher in the call stack.
> >> 
> >> I'm not convinced it is a good idea to have such a dependency, even
> >> more so with this cloudy a reference. If there's another XSM check
> >> that has necessarily been done before, you should at least name it
> >> here so it's easy to later verify that the assumption still holds. But
> >> even better would imo be to re-do the check here, just in case.
> > 
> > I am fine with that. It should be just a matter of doing the following,
> > right?
> > 
> > static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain *d,
> >  struct domain *t)
> > {
> > XSM_ASSERT_ACTION(XSM_TARGET);
> > return xsm_default_action(XSM_TARGET, current->domain, d) &&
> >xsm_default_action(action, current->domain, t);
> 
> Not exactly - xsm_default_action() doesn't return boolean, nor should
> the function here.

You are right, zero is success. So something like the following:

int rc = xsm_default_action(XSM_TARGET, current->domain, d);
if ( rc )
return rc;
return xsm_default_action(action, current->domain, t);


> >> > --- a/xen/xsm/flask/hooks.c
> >> > +++ b/xen/xsm/flask/hooks.c
> >> > @@ -1198,6 +1198,17 @@ static int flask_map_gmfn_foreign(struct domain 
> >> > *d, struct domain *t)
> >> >  return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | 
> >> > MMU__MAP_WRITE);
> >> >  }
> >> >  
> >> > +/*
> >> > + * This action also requires that @current has MMU__MAP_READ/WRITE over 
> >> > @d,
> >> > + * but that has already been checked somewhere higher in the call stack 
> >> > (for
> >> > + * example, by flask_add_to_physmap()).
> >> 
> >> This one's better in that it at least names the other hook. Still I'm
> >> not fully convinced that omitting the other half of the check here
> >> is prudent. We'll see what others think ...
> > 
> > Sure, it should be simple to change (I hope I am not missing something).
> > 
> > static int flask_map_gmfn_share(struct domain *d, struct domain *t)
> > {
> >   return current_has_perm(d, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE) 
> > &&
> >  (current_has_perm(t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE) 
> > ?:
> >   domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM));
> 
> Same here afaict.

Yep:

int rc = current_has_perm(d, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
if ( rc )
return rc;
rc = current_has_perm(t, SECCLASS_MMU, MMU__MAP_READ | MMU__MAP_WRITE);
if ( rc )
return rc;
return domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM);

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

Re: [Xen-devel] [PATCH net-next] xen-netback: use true and false for boolean values

2018-08-02 Thread David Miller

From: "Gustavo A. R. Silva" 
Date: Wed, 1 Aug 2018 19:31:01 -0500

> Return statements in functions returning bool should use true or false
> instead of an integer value.
> 
> This issue was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

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

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

2018-08-02 Thread Kees Cook

On Thu, Aug 2, 2018 at 12:22 PM, Srivatsa S. Bhat
 wrote:
> On 7/26/18 4:09 PM, Kees Cook wrote:
>> On Tue, Jul 24, 2018 at 3:02 PM, Jiri Kosina  wrote:
>>> On Tue, 24 Jul 2018, Srivatsa S. Bhat wrote:
>>>
 However, if you are proposing that you'd like to contribute the enhanced
 PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and
 have them merged instead of this patch series, then I would certainly
 welcome it!
>>>
>>> I'd in principle love us to push everything back to 4.4, but there are a
>>> few reasons (*) why that's not happening shortly.
>>>
>>> Anyway, to point out explicitly what's really needed for those folks
>>> running 4.4-stable and relying on PTI providing The Real Thing(TM), it's
>>> either a 4.4-stable port of
>>>
>>> 
>>> http://kernel.suse.com/cgit/kernel-source/plain/patches.suse/x86-entry-64-use-a-per-cpu-trampoline-stack.patch?id=3428a77b02b1ba03e45d8fc352ec350429f57fc7
>>>
>>> or making THREADINFO_GFP imply __GFP_ZERO.
>>
>> This is true in Linus's tree now. Should be trivial to backport:
>> https://git.kernel.org/linus/e01e80634ecdd
>>
>
> Hi Jiri, Kees,
>
> Thank you for suggesting the patch! I have attached the (locally
> tested) 4.4 and 4.9 backports of that patch with this mail. (The
> mainline commit applies cleanly on 4.14).
>
> Greg, could you please consider including them in stable 4.4, 4.9
> and 4.14?

I don't think your v4.9 is sufficient: it leaves the vmapped stack
uncleared. v4.9 needs ca182551857 ("kmemleak: clear stale pointers
from task stacks") included in the backport (really, just adding the
memset()).

Otherwise, yup, looks good.

-Kees

-- 
Kees Cook
Pixel Security

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

[Xen-devel] [linux-next test] 125724: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 125676
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 125676
 build-arm64   4 host-install(4)broken REGR. vs. 125676
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 125676
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 125676
 test-amd64-amd64-xl-shadow   10 debian-install   fail REGR. vs. 125676
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 125676
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125676
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 125676
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
125676
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 125676
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 125676
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 125676
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 125676
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
125676
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
125676
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 125676
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 125676
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 125676
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125676
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 125676
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 125676
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125676
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 125676
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125676
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 125676
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
125676
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125676
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125676
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 125676
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 125676
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 125676
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 125676
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 125676
 test-amd64-amd64-libvirt-xsm 10 debian-install   fail REGR. vs. 125676
 test-amd64-i386-xl-qemu

[Xen-devel] [linux-linus test] 125735: trouble: blocked/broken/fail/pass

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 125702

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

version targeted for testing:
 linux44960f2a7b63e224b1091b3e1d6f60e0cdf4be0c
baseline version:
 linux527838d470e3a6e79e8ee9d5ddf28920df2a196e

Last test of basis   125702  2018-07-31 14:25:44 Z2 days
Testing same since   125735  2018-08-01 18:37:38 Z1 days1 attempts

--

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

2018-08-02 Thread Platform Team regression test user

flight 75038 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75038/

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

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.xensource.com/osstest/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.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.6-testing baseline-only test] 75037: regressions - FAIL

2018-08-02 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 75037 xen-4.6-testing real [real]
http://osstest.xensource.com/osstest/logs/75037/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-521 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 74930
 test-xtf-amd64-amd64-421 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 74930
 test-xtf-amd64-amd64-5 36 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 74930
 test-xtf-amd64-amd64-4 36 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 74930
 test-xtf-amd64-amd64-549 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 74930
 test-xtf-amd64-amd64-449 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 74930

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1   21 xtf/test-hvm32-invlpg~shadow fail   like 74930
 test-xtf-amd64-amd64-1  36 xtf/test-hvm32pae-invlpg~shadow fail like 74930
 test-xtf-amd64-amd64-1   49 xtf/test-hvm64-invlpg~shadow fail   like 74930
 test-armhf-armhf-libvirt 12 guest-start  fail   like 74930
 test-armhf-armhf-xl-multivcpu 12 guest-start  fail  like 74930
 test-armhf-armhf-xl-midway   12 guest-start  fail   like 74930
 test-armhf-armhf-xl-credit2  12 guest-start  fail   like 74930
 test-armhf-armhf-xl  12 guest-start  fail   like 74930
 test-armhf-armhf-xl-rtds 12 guest-start  fail   like 74930
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74930
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 74930
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 74930
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 74930
 test-armhf-armhf-xl-vhd  10 debian-di-installfail   like 74930
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail   like 74930
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 74930
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-xtf-amd64-amd64-4   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  98d7948b50b4e91ec4efa860da32d9ac4fe69300
baseline version:
 xen  598a375f5230d91ac88e76a9f4b4dde4a62a4c5b

Last test of basis74930  2018-07-03 05:14:52 Z   30 days
Testing same since75037  2018-08-02 00:02:42 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf de652b14a78b4767ff460999b6728d7ccc50b057
baseline version:
 ovmf 3a0c1bf64b5deaa4e227b311cc43aa1513beae5e

Last test of basis   125740  2018-08-02 09:10:45 Z0 days
Testing same since   125746  2018-08-02 22:10:47 Z0 days1 attempts


People who touched revisions under test:
  Kinney, Michael D 
  Michael D Kinney 
  Star Zeng 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   3a0c1bf64b..de652b14a7  de652b14a78b4767ff460999b6728d7ccc50b057 -> 
xen-tested-master

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

[Xen-devel] [libvirt test] 125739: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 123814
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 123814
 build-arm64   4 host-install(4)broken REGR. vs. 123814
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  8e09f9afc712712f8a4747c69836800a11a6f6f3
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z   58 days
Failing since123840  2018-06-06 04:19:28 Z   57 days   45 attempts
Testing same since   125739  2018-08-02 08:43:19 Z0 days1 attempts


People who touched revisions under test:
Ales Musil 
  Andrea Bolognani 
  Anya Harter 
  Bjoern Walk 
  Bobo Du 
  Boris Fiuczynski 
  Brijesh Singh 
  Changkuo Shi 
  Chen Hanxiao 
  Christian Ehrhardt 
  Cole Robinson 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Erik Skultety 
  Fabiano Fidêncio 
  Filip Alac 
  Han Han 
  intrigeri 
  intrigeri 
  Jamie Strandboge 
  Jie Wang 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Katerina Koukiou 
  Laine Stump 
  Laszlo Ersek 
  Luyao Huang 
  Marc Hartmayer 
  Marc Hartmayer 
  Marcos Paulo de Souza 
  Martin Kletzander 
  Michal Privoznik 
  Michal Prívozník 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shi Lei 
  Shichangkuo 
  Simon Kobyda 
  Stefan Bader 
  Stefan Berger 
  Sukrit Bhatnagar 
  Tomáš Golembiovský 
  w00251574 
  Weilun Zhu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-ar

[Xen-devel] [ovmf baseline-only test] 75039: tolerable FAIL

2018-08-02 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 75039 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75039/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75036
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75036

version targeted for testing:
 ovmf 3a0c1bf64b5deaa4e227b311cc43aa1513beae5e
baseline version:
 ovmf 7343bc8062c893ed6d40b25a9329d51340e0d703

Last test of basis75036  2018-08-01 17:53:04 Z1 days
Testing same since75039  2018-08-02 13:21:16 Z0 days1 attempts


People who touched revisions under test:
  Alexei Fedorov 
  AlexeiFedorov 
  Kinney, Michael D 
  Michael D Kinney 
  Star Zeng 
  Sumit Garg 
  Yunhua Feng 

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  fail



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


commit 3a0c1bf64b5deaa4e227b311cc43aa1513beae5e
Author: Yunhua Feng 
Date:   Tue Jul 31 16:32:57 2018 +0800

BaseTools: Use pickle to replace cPickle

Use pickle to replace cPickle because of python3 removed cPickle

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

commit 26067e30c48da27df41252444fce66a6418a613b
Author: Yunhua Feng 
Date:   Tue Jul 31 15:19:28 2018 +0800

BaseTools: remove unused import thread

remove unused import thread

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

commit 68bef3f0c7c71da2f065fd348efa79f04799d347
Author: AlexeiFedorov 
Date:   Fri Jul 13 23:17:01 2018 +0800

ShellPkg/UefiShellAcpiViewCommandLib: Fix VS2017 compilation errors

This patch fixes VS2017 compilation errors for
UefiShellAcpiViewCommandLib\Parsers\Gtdt\GtdtParser.c
and
UefiShellAcpiViewCommandLib\Parsers\Xsdt\XsdtParser.c
reported in
https://bugzilla.tianocore.org/show_bug.cgi?id=985
https://bugzilla.tianocore.org/show_bug.cgi?id=986

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Alexei Fedorov 
Reviewed-by: Jaben Carsey 

commit 76c09700edc67686b29662e81a3ca7d947594ce5
Author: Kinney, Michael D 
Date:   Tue Jul 31 09:24:20 2018 -0700

BaseTools/BinToPcd: Fix Python 2.7.x compatibility issue

https://bugzilla.tianocore.org/show_bug.cgi?id=1042

Convert Buffer to type bytearray before converting to a
string of hex byte values so the type of items in Buffer is
consistent for both Python 2.7.x and Python 3.x.

Cc: YanYan Sun 
Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Yonghong Zhu 

commit d65b78f101b3f2845dc20b9556faf3f14904f3c5
Author: Sumit Garg 
Date:   Wed Aug 1 11:37:41 2018 +0530

ArmPkg: Add initial OpteeLib implementation

This is initial version of OP-TEE library that provides api's to
communicate with OP-TEE OS (Trusted OS based on ARM TrustZone) via
secure monitor calls. Currently it provides basic api to detect OP-TEE
presence via UID matching.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sumit Garg 
Reviewed-by: Ard Biesheuvel 

commit 52437cb7633bc1811c53899c8981364c71246a26
Author: Star Zeng 
Date:   Mon Jul 30 17:43:13 2018 +0800

MdePkg FirmwareManagement.h: Fix code style issue

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Hess Chen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Michael D Kinney 
Reviewed-by: Dandan Bi 

commit

[Xen-devel] [xen-4.7-testing test] 125737: regressions - trouble: blocked/broken/fail/pass