Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Wed, Apr 27, 2016 at 05:39:40AM +, Ni, Ruiyu wrote:
> 
> 
> Regards,
> Ray
> 
> >-Original Message-
> >From: Gary Lin [mailto:g...@suse.com]
> >Sent: Wednesday, April 27, 2016 12:29 PM
> >To: Ni, Ruiyu 
> >Cc: edk2-de...@lists.01.org; Xen Devel 
> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >On Tue, Apr 26, 2016 at 09:40:42AM +, Ni, Ruiyu wrote:
> >> Gary,
> >> I can reproduce the issue and have debugged to get the reason.
> >> In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
> >> PciEnumeratorLight() calls PciRootBridgeIo->Configuration()
> >> while the Configuration returns EFI_UNSUPPORTED resulting
> >> the PciBus driver exits earlier.
> >> You could try to manually set MinBus to 0 and MaxBus to 0xFF.
> >>
> >Do you mean to set MinBus and MaxBus in PciGetBusRange() ?
> >Should I also keep the EFI_UNSUPPORTED code in Configuration() ?
> Keep returning EFI_UNSUPPORTED in Configuration() and set
> MinBus/MaxBus in PciGetBusRange().
> 
> >
> >> The second change you need to make is in PciIo.c:
> >> Change GetMmioAddressTranslationOffset() to return 0 instead
> >> of -1 when error occurs
> >>
> >
> >Should I also remove "ASSERT (FALSE);" ?
> 
> 
> ASSERT() won't be hit.
> 
It didn't work (see my attached patch) :(
BTW, if Configuration() already returns EFI_UNSUPPORTED, then there is
no way to invoke PciGetBusRange(). Besides, MaxBus was never used in
PciEnumeratorLight(), so it's meaningless to assign any value to it.

Cheers,

Gary Lin

> >
> >Cheers,
> >
> >Gary Lin
> >
> >> With the above 2 changes, can you check whether the system can
> >> boot?
> >>
> >> If it can boot, then we need to think about what the proper fix is.
> >> For OVMF above Xen, the PCI resources are assigned by Xen other than
> >> PciBus driver. So PciRootBridgeIo->Configuration() doesn't know
> >> the resource assignment information.
> >> With old PciHostBridge driver, the Configuration() returns BUS resource
> >> descriptor with MinBus = MaxBus = 0 (default value), so that the PciBus
> >> driver can detect all devices in BUS 0, but I guess devices in BUS 1+ 
> >> cannot
> >> be detected.
> >>
> >> Does Xen pass the resource assignment information through some memory
> >> blob to firmware? If yes, we could think about let PciHostBridgeLib pass 
> >> that
> >> information to PciHostBridge driver. If no, we also could let 
> >> PciHostBridgeLib
> >> collect the information (IO/MEM/BUS resource assignment) and pass that
> >> to PciHostBridgeDxe driver.
> >>
> >> And we need to have a way to tell PciHostBridgeDxe the resource information
> >> passed from PciHostBridgeLib is available resource to assign, or already 
> >> allocated.
> >> Maybe just depends on the PcdPciBusDisableEnumeration. still thinking.
> >>
> >>
> >> Regards,
> >> Ray
> >>
> >> >-Original Message-
> >> >From: Gary Lin [mailto:g...@suse.com]
> >> >Sent: Tuesday, April 26, 2016 4:40 PM
> >> >To: Ni, Ruiyu 
> >> >Cc: edk2-de...@lists.01.org; Xen Devel 
> >> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >> >
> >> >On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
> >> >> Gary,
> >> >> Maybe the system boots to Shell well but the video isn't initialized 
> >> >> properly.
> >> >> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
> >> >> give me the boot log?
> >> >>
> >> >Hi Ray,
> >> >
> >> >I already did and it's how I make the firmware spit the log :-(
> >> >
> >> >Thanks,
> >> >
> >> >Gary Lin
> >> >
> >> >> Regards,
> >> >> Ray
> >> >>
> >> >> From: Gary Lin [mailto:g...@suse.com]
> >> >> Sent: Tuesday, April 26, 2016 3:35 PM
> >> >> To: Ni, Ruiyu 
> >> >> Cc: Anthony PERARD ; 
> >> >> edk2-de...@lists.01.org; Xen Devel 
> >> >> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >> >>
> >> >> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> > Ray
> >> >> >
> >> >> > >-Original Message-
> >> >> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >> >> > >Of Anthony PERARD
> >> >> > >Sent: Friday, April 22, 2016 10:48 PM
> >> >> > >To: edk2-de...@lists.01.org
> >> >> > >Cc: Xen Devel 
> >> >> > >mailto:xen-devel@lists.xen.org>>
> >> >> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
> >> >> > >
> >> >> > >Hi,
> >> >> > >
> >> >> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the 
> >> >> > >pci root
> >> >> > >bridge does not finish to initialize and breaks under Xen.
> >> >> > >
> >> >> > >There are several issue probably due to the use of
> >> >> > >PcdPciDisableBusEnumeration=TRUE.
> >> >> > >
> >> >> > >First one:
> >> >> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> >> >> > >Bridge->Mem.Limit <
> >> >0x0001ULL
> >> >> > >
> >> >> > >This patch would fix the first assert:
> >> >> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/

Re: [Xen-devel] [PATCH v9 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Jan Beulich]

>>> On 26.04.16 at 19:50,  wrote:
> On Tue, Apr 26, 2016 at 04:21:10AM -0600, Jan Beulich wrote:
>> >>> On 25.04.16 at 17:34,  wrote:
>> > The implementation does not actually do any patching.
>> > 
>> > It just adds the framework for doing the hypercalls,
>> > keeping track of ELF payloads, and the basic operations:
>> >  - query which payloads exist,
>> >  - query for specific payloads,
>> >  - check*1, apply*1, replace*1, and unload payloads.
>> > 
>> > *1: Which of course in this patch are nops.
>> > 
>> > The functionality is disabled on ARM until all arch
>> > components are implemented.
>> > 
>> > Also by default it is disabled until the implementation
>> > is in place.
>> > 
>> > We also use recursive spinlocks to so that the find_payload
>> > function does not need to have a 'lock' and 'non-lock' variant.
>> > 
>> > Signed-off-by: Konrad Rzeszutek Wilk 
>> > Signed-off-by: Ross Lagerwall 
>> > Reviewed-by: Andrew Cooper 
>> > Acked-by: Daniel De Graaf 
>> 
>> I'm hesitant to say that, but with all of this:
>> 
>> > v9:
>> > s/find_name/get_name/, drop locks when allocating data.
>> > Drop conditional expression on copyback
>> > Move the allocation on upload outside the spinlock.
>> > Add (TECH PREVIEW) to the Kconfig help
>> > Return -EINVAL if the CHECK or UNLOAD action is to be performed and 
>> > the payload
>> > state is not in expected state.
>> > Print 'c' not 'u' when invoking the keyhandler.
>> 
>> ... I'm not sure the earlier R-b can still be considered valid. Andrew?
> 
> I don't know what the criteria is for dropping an Reviewed-by.
> I am happy to drop it if you would like - but it may be that Andrew
> is OK with the way he had his review?
> 
> Or is this more of your view as maintainer - that is the patch
> changed considerably (and what is that? percentage of the patch?
> small amount of the patch? Trivial changes? Dropping code?)?

Indeed, that's the aspects that matter: _Any_ non-trivial change
to the area a tag was offered of should lead to the tag getting
dropped. That is, if you make substantial changes to e.g. non-XSM
parts but have an XSM ack, that can of course stay.

Among the above, the obviously (to me) non-trivial changes are
the ordering adjustment of allocation vs locking.

>> > +static int get_name(const xen_xsplice_name_t *name, char *n)
>> > +{
>> > +if ( !name->size || name->size > XEN_XSPLICE_NAME_SIZE )
>> > +return -EINVAL;
>> > +
>> > +if ( name->pad[0] || name->pad[1] || name->pad[2] )
>> > +return -EINVAL;
>> > +
>> > +if ( !guest_handle_okay(name->name, name->size) )
>> > +return -EINVAL;
>> > +
>> > +if ( __copy_from_guest(n, name->name, name->size) )
>> > +return -EFAULT;
>> 
>> Quoting part of my v8.1 reply:
>> "Is there a particular reason why you open code copy_from_guest() here?"
> 
> You mean why I use guest_handle_okay and __copy_from_guest instead of
> say copy_from_guest?
> 
> I think it is an artificat of earlier changes - in which the find_name
> would only check 'name-size' and then in another function we would
> just do '__copy_from_guest'. But that is not needed anymore - so let
> me change it to 'copy_from_guest'

Right, but that change didn't happen.

> I thought at some point you asked for that as the check was done for
> it once and there was no point

This may well have been in some much earlier version, where the
two lived in different places. But when they're together, they
clearly should be folded back.

>> > +static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
>> > +{
>> > +struct payload *data, *found;
>> > +char n[XEN_XSPLICE_NAME_SIZE];
>> > +int rc;
>> > +
>> > +rc = verify_payload(upload, n);
>> > +if ( rc )
>> > +return rc;
>> > +
>> > +data = xzalloc(struct payload);
>> > +
>> > +spin_lock(&payload_lock);
>> > +
>> > +found = find_payload(n);
>> > +if ( IS_ERR(found) )
>> > +{
>> > +rc = PTR_ERR(found);
>> > +goto out;
>> > +}
>> > +else if ( found )
>> > +{
>> > +rc = -EEXIST;
>> > +goto out;
>> > +}
>> > +
>> > +if ( !data )
>> > +{
>> > +rc = -ENOMEM;
>> > +goto out;
>> > +}
>> > +
>> > +rc = 0;
>> 
>> rc is already zero by the time we get here.
>> 
>> I also wonder whether the code wouldn't be easier to read if you
>> used just a sequence of if()/else if() here, without any goto-s.
> 
> But I do need to free(data) and unlock the spinlock - so having
> a common code to pass through makes sense.
> 
> Unless you mean have an condition on if ( !rc ), and do the normal path?
> Like so:
> 
> rc = verify_payload(upload, n);
> if ( rc )
> return rc;
> 
> data = xzalloc(struct payload);
> 
> spin_lock(&payload_lock);
> 
> found = find_payload(n);
> if ( IS_ERR(found) )
> rc = PTR_ERR(found);
> else if ( found )
> rc = -EEXIST;
> 
> if ( !rc && !data )

This can just b

Re: [Xen-devel] [PATCH v2 07/11] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).

[Jan Beulich]

>>> On 27.04.16 at 08:21,  wrote:
> On April 26, 2016 8:49 PM, Jan Beulich  wrote:
>> Hmm, the "positive" here has nothing to do with the "positive" in patch 1.
>> Please just have a look at xenmem_add_to_physmap() as a whole.
>> 
> 
> Thanks for reminding me. The 'positive'  is ' rc = start + done'..
> 
> Think twice, I found I need two other new return values for this  function  
> (correct me if I am wrong!).
> If the first iommu_iotlb_flush() is failed, I shouldn't  accumulate the 
> return value of
> the second iommu_iotlb_flush() -- but instead properly accumulate the return 
> value.

I think just one will do.

> The following is my modification:
> 
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -640,6 +640,10 @@ static int xenmem_add_to_physmap(struct domain *d,
>  unsigned int done = 0;
>  long rc = 0;
> 
> +#ifdef CONFIG_HAS_PASSTHROUGH
> +int ret, rv;
> +#endif

This should go into the scope below, allowing to avoid the extra
#ifdef.

> @@ -678,8 +682,15 @@ static int xenmem_add_to_physmap(struct domain *d,
>  if ( need_iommu(d) )
>  {
>  this_cpu(iommu_dont_flush_iotlb) = 0;
> -iommu_iotlb_flush(d, xatp->idx - done, done);
> -iommu_iotlb_flush(d, xatp->gpfn - done, done);
> +ret = iommu_iotlb_flush(d, xatp->idx - done, done);
> +
> +if ( rc >= 0 && ret < 0 )

Why "ret < 0" instead of just "ret"?

> +rc = ret;
> +
> +rv = iommu_iotlb_flush(d, xatp->gpfn - done, done);
> +
> +if ( rc >=0 && ret == 0 && rv < 0 )
> +rc = rv;

I don't see the middle part being needed here, eliminating the
need for "rv".

Jan


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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Jan Beulich]

>>> On 26.04.16 at 19:39,  wrote:
> On 26/04/16 18:23, Razvan Cojocaru wrote:
>> Regarding this version of the patch, Jan has asked for more information
>> on the performance impact, but I'm not sure how to obtain it in a
>> rigorous manner. If it is decided that a version of this patch is
>> desirable, I can go on fixing the issues we've found and address the
>> comments we've had so far and submit a new version.
> 
> XenServer did performance testing.  No observable impact for normal VM
> workloads (which is to be expected, as an OS wouldn't normally LOCK the
> instructions it uses for MMIO).  The per-cpu rwlocks have ~0 overhead
> when the lock isn't held for writing.

So how about PV guests doing locked page table updates, or the
impact on log-dirty mode?

Jan


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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Jan Beulich]

>>> On 26.04.16 at 19:23,  wrote:
> On 04/26/16 19:03, George Dunlap wrote:
>> On 19/04/16 17:35, Jan Beulich wrote:
>> Razvan Cojocaru  04/19/16 1:01 PM >>>
 I think this might be because the LOCK prefix should guarantee that the
 instruction that follows it has exclusive use of shared memory (for both
 reads and writes) but I might be misreading the docs:
>>>
>>> LOCK definitely has no effect on other than the instruction it gets applied
>>> to.
>> 
>> Sorry I wasn't involved in this discussion -- what was the conclusion here?
>> 
>> FWIW Andy's suggestion of using a stub seemed like the most robust
>> solution, if that could be made to work.
>> 
>> If you're going to submit a patch substantially similar to this one, let
>> me know so I can review the mm bits of the original patch.
> 
> I'm not really sure.
> 
> Regarding this version of the patch, Jan has asked for more information
> on the performance impact, but I'm not sure how to obtain it in a
> rigorous manner.

That was only one half, which Andrew has now answered. The
other was the not understood issue with a later variant you had
tried.

Jan


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

Re: [Xen-devel] [PATCH v2 07/11] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).

[Xu, Quan]

On April 26, 2016 8:49 PM, Jan Beulich  wrote:
> >>> On 26.04.16 at 14:23,  wrote:
> > On April 25, 2016 6:19 PM,  Jan Beulich  wrote:
> >> >>> On 18.04.16 at 16:00,  wrote:
> >> > --- a/xen/common/memory.c
> >> > +++ b/xen/common/memory.c
> >> > @@ -678,8 +678,9 @@ static int xenmem_add_to_physmap(struct
> domain
> >> *d,
> >> >  if ( need_iommu(d) )
> >> >  {
> >> >  this_cpu(iommu_dont_flush_iotlb) = 0;
> >> > -iommu_iotlb_flush(d, xatp->idx - done, done);
> >> > -iommu_iotlb_flush(d, xatp->gpfn - done, done);
> >> > +rc = iommu_iotlb_flush(d, xatp->idx - done, done);
> >> > +if ( !rc )
> >> > +rc = iommu_iotlb_flush(d, xatp->gpfn - done, done);
> >>
> >> And again - best effort flushing in all cases. I.e. you shouldn't
> >> bypass the second one if the first one failed, but instead properly
> >> accumulate the return value, and also again not clobber any negative value
> rc may already hold.
> >
> >
> > Thanks for correcting me. I did like accumulating the return value.
> > :( I will follow your suggestion in next v3.
> >
> >> What's worse (and makes me wonder whether this got tested) - you also
> >> clobber the positive return value this function may produce, even in
> >> the case the flushes succeed (and hence the function as a whole was
> successful).
> >>
> > I have tested it with previous patches (i.e.  1st patch), launching a
> > VM with PT ATS device to invoke this call tree.
> > btw, I fix the positive issue in 1st patch.
> > I know this is not strict, as I assume this patch set will be
> > committed at the same time.
> 
> Hmm, the "positive" here has nothing to do with the "positive" in patch 1.
> Please just have a look at xenmem_add_to_physmap() as a whole.
> 

Thanks for reminding me. The 'positive'  is ' rc = start + done'..

Think twice, I found I need two other new return values for this  function  
(correct me if I am wrong!).
If the first iommu_iotlb_flush() is failed, I shouldn't  accumulate the return 
value of
the second iommu_iotlb_flush() -- but instead properly accumulate the return 
value.

The following is my modification:

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -640,6 +640,10 @@ static int xenmem_add_to_physmap(struct domain *d,
 unsigned int done = 0;
 long rc = 0;

+#ifdef CONFIG_HAS_PASSTHROUGH
+int ret, rv;
+#endif
+
 if ( xatp->space != XENMAPSPACE_gmfn_range )
 return xenmem_add_to_physmap_one(d, xatp->space, DOMID_INVALID,
  xatp->idx, xatp->gpfn);
@@ -678,8 +682,15 @@ static int xenmem_add_to_physmap(struct domain *d,
 if ( need_iommu(d) )
 {
 this_cpu(iommu_dont_flush_iotlb) = 0;
-iommu_iotlb_flush(d, xatp->idx - done, done);
-iommu_iotlb_flush(d, xatp->gpfn - done, done);
+ret = iommu_iotlb_flush(d, xatp->idx - done, done);
+
+if ( rc >= 0 && ret < 0 )
+rc = ret;
+
+rv = iommu_iotlb_flush(d, xatp->gpfn - done, done);
+
+if ( rc >=0 && ret == 0 && rv < 0 )
+rc = rv;
 }
 #endif


Quan

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

Re: [Xen-devel] [PATCH v2] xen/arm: gicv2: Export GICv2m register frames to domain0 by device tree

[Wei Chen]

Hi Julien,

On 26 April 2016 at 18:49, Julien Grall  wrote:
> Hello Wei,
>
> On 25/04/2016 10:39, Wei Chen wrote:
>>
>> This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
>> detects the MSI frames from device tree and creates corresponding device
>> tree nodes in Domain0's DTB. It also provides one hw_ops callback to map
>
>
> NIT: s/Domain0/dom0/
>
>> v2m MMIO regions to domain0 and route v2m SPIs to domain0.
>
>
> Ditto.
>
>>
>> With this GICv2m extension support, the domain0 kernel can do GICv2m
>
>
> Ditto
>
>> frame setup and initialization.
>>
>> This patch is based on the GICv2m patch of Suravee Suthikulpanit:
>> [PATCH 2/2] xen/arm: gicv2: Adding support for GICv2m in Dom0
>> http://lists.xen.org/archives/html/xen-devel/2015-04/msg02613.html
>>
>> Signed-off-by: Wei Chen 
>
>
> [...]
>
>> +static int gicv2_map_hwdown_extra_mappings(struct domain *d)
>> +{
>> +const struct v2m_data *v2m_data;
>> +
>> +/* For the moment, we'll assign all v2m frames to the hardware
>> domain. */
>> +list_for_each_entry( v2m_data, &gicv2m_info, entry )
>> +{
>> +int ret;
>> +u32 spi;
>> +
>> +printk("GICv2: Mapping v2m frame to d%d: addr=0x%lx size=0x%lx
>> spi_base=%u num_spis=%u\n",
>> +   d->domain_id, v2m_data->addr, v2m_data->size,
>> +   v2m_data->spi_start, v2m_data->nr_spis);
>> +
>> +ret = map_mmio_regions(d, paddr_to_pfn(v2m_data->addr),
>> +DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
>> +paddr_to_pfn(v2m_data->addr));
>> +if ( ret )
>> +{
>> +printk(XENLOG_ERR "GICv2: Map v2m frame to s%d failed.\n",
>
>
> s/s%d/d%d/
>
>> +   d->domain_id);
>> +return ret;
>> +}
>> +
>> +/*
>> + * Map all SPIs that are allocated to MSIs for the frame to the
>> + * domain.
>> + */
>> +for ( spi = v2m_data->spi_start;
>> +  spi < (v2m_data->spi_start + v2m_data->nr_spis); spi++ )
>> +{
>> +/*
>> + * MSIs are always edge-triggered. Configure the associated
>> SPIs
>> + * to be edge-rising.
>
>
> How did you find that SPIs should be configured edge-rising?
Before route_irq_to_guest, the SPI must be configured. I found Linux
v2m driver set
the SPI type to edge-rising, so I set edge-rising as v2m SPI default
type here too.
>
>
>> + */
>> +ret = irq_set_spi_type(spi, IRQ_TYPE_EDGE_RISING);
>> +if ( ret )
>> +{
>> +printk(XENLOG_ERR
>> +   "GICv2: Failed to set v2m MSI SPI[%d] type.\n",
>> spi);
>> +return ret;
>> +}
>> +
>> +/* Route a SPI that is allocated to MSI to the domain. */
>> +ret = route_irq_to_guest(d, spi, spi, "v2m");
>> +if ( ret )
>> +{
>> +printk(XENLOG_ERR
>> +   "GICv2: Failed to route v2m MSI SPI[%d] to
>> Dom%d.\n",
>> +spi, d->domain_id);
>> +return ret;
>> +}
>> +
>> +/* Reserve a SPI that is allocated to MSI for the domain. */
>> +if ( !vgic_reserve_virq(d, spi) )
>> +{
>> +printk(XENLOG_ERR
>> +   "GICv2: Failed to reserve v2m MSI SPI[%d] for
>> Dom%d.\n",
>> +spi, d->domain_id);
>> +return -EINVAL;
>> +}
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/*
>> + * Set up gic v2m DT sub-node.
>> + * Please refer to the binding document:
>> + *
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
>> + */
>> +static int gicv2m_make_dt_node(const struct domain *d,
>> +const struct dt_device_node *gic,
>> +void *fdt)
>
>
> The indentation is still wrong here.
>
> The start of the second and third lines should be aligned to "const..." on
> the first line. I.e
>
> foo(const
> const
> void
>
> Where _ is the empty space.
>
> [...]
>

Thanks for your detailed example!

>> +static void gicv2_add_v2m_frame_to_list(paddr_t addr, paddr_t size,
>> +u32 spi_start, u32 nr_spis,
>> +const struct dt_device_node *v2m)
>> +{
>> +struct v2m_data *v2m_data;
>> +
>> +v2m_data = xzalloc_bytes(sizeof(struct v2m_data));
>> +if ( !v2m_data )
>> +panic("GICv2: Cannot allocate memory for v2m frame");
>> +
>> +/* Initialize a new entry to record new frame infomation. */
>
>
> s/infomation/information/
>
>
>> +INIT_LIST_HEAD(&v2m_data->entry);
>> +v2m_data->addr = addr;
>> +v2m_data->size = size;
>> +v2m_data->spi_start = spi_start;
>> +v2m_data->nr_spis = nr_spis;
>> +v2m_data->dt_node = v2m;
>> +
>> +printk("GICv2m extensio

Re: [Xen-devel] [Xen-users] How to install Xen on Fedora 23?

[Jason Long]

Can it work on Workstation version too? Or just server version of fedora needed?



On Wednesday, April 27, 2016 9:53 AM, Jason Long  wrote:
Not matter.
I did it too :

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.7-300.fc23.i686
Found initrd image: /boot/initramfs-4.4.7-300.fc23.i686.img
Found linux image: /boot/vmlinuz-4.2.3-300.fc23.i686
Found initrd image: /boot/initramfs-4.2.3-300.fc23.i686.img
Found linux image: /boot/vmlinuz-0-rescue-204e260309794cee901bd6e0b46ace3a
Found initrd image: 
/boot/initramfs-0-rescue-204e260309794cee901bd6e0b46ace3a.img
done


Problem not solved :(




On Wednesday, April 27, 2016 9:06 AM, Konrad Rzeszutek Wilk 
 wrote:
On Tue, Apr 26, 2016 at 03:00:21PM +, Jason Long wrote:
> Hello.
> I installed Fedora 23 x64 on my PC and id below command for installing Xen :
> 
> # cd /etc/yum.repos.d/
> # wget http://fedorapeople.org/groups/virt/...t-preview.repo

Why? No need for that.
> # yum update
> # yum -y install xen xen-hypervisor xen-libs xen-runtime
> # systemctl enable xend.service
> # systemctl enable xendomains.service
> 
> After it I run below command :

You are missing 'grub2-mkconfig -o /boot/grub2/grub.cfg'


> 
> # grep ^menuentry /boot/grub2/grub.cfg | cut -d "'" -f2

> Fedora (4.4.7-300.fc23.i686) 23 (Workstation Edition)
> Fedora (4.2.3-300.fc23.i686) 23 (Workstation Edition)
> Fedora (0-rescue-204e260309794cee901bd6e0b46ace3a) 23 (Workstation Edition)
> 
> But, I can't see any "Fedora, with Xen hypervisor" !!! and when I run "xl 
> info" it show me below error :
> 
> # xl info
> xc: error: Could not obtain handle on privileged command interface (2 = No 
> such file or directory): Internal error
> libxl: error: libxl.c:114:libxl_ctx_alloc: cannot open libxc handle: No such 
> file or directory
> cannot init xl context
> 
> How can I solve it?
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-users mailing list
xen-us...@lists.xen.org
http://lists.xen.org/xen-users 

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

[Xen-devel] [ovmf test] 92910: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 19c25725606b848986f29bb3a216857146fdacb9
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  140 days
Failing since 65593  2015-12-08 23:44:51 Z  140 days  182 attempts
Testing same since92910  2016-04-27 03:04:58 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Regards,
Ray

>-Original Message-
>From: Gary Lin [mailto:g...@suse.com]
>Sent: Wednesday, April 27, 2016 12:29 PM
>To: Ni, Ruiyu 
>Cc: edk2-de...@lists.01.org; Xen Devel 
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On Tue, Apr 26, 2016 at 09:40:42AM +, Ni, Ruiyu wrote:
>> Gary,
>> I can reproduce the issue and have debugged to get the reason.
>> In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
>> PciEnumeratorLight() calls PciRootBridgeIo->Configuration()
>> while the Configuration returns EFI_UNSUPPORTED resulting
>> the PciBus driver exits earlier.
>> You could try to manually set MinBus to 0 and MaxBus to 0xFF.
>>
>Do you mean to set MinBus and MaxBus in PciGetBusRange() ?
>Should I also keep the EFI_UNSUPPORTED code in Configuration() ?
Keep returning EFI_UNSUPPORTED in Configuration() and set
MinBus/MaxBus in PciGetBusRange().

>
>> The second change you need to make is in PciIo.c:
>> Change GetMmioAddressTranslationOffset() to return 0 instead
>> of -1 when error occurs
>>
>
>Should I also remove "ASSERT (FALSE);" ?


ASSERT() won't be hit.

>
>Cheers,
>
>Gary Lin
>
>> With the above 2 changes, can you check whether the system can
>> boot?
>>
>> If it can boot, then we need to think about what the proper fix is.
>> For OVMF above Xen, the PCI resources are assigned by Xen other than
>> PciBus driver. So PciRootBridgeIo->Configuration() doesn't know
>> the resource assignment information.
>> With old PciHostBridge driver, the Configuration() returns BUS resource
>> descriptor with MinBus = MaxBus = 0 (default value), so that the PciBus
>> driver can detect all devices in BUS 0, but I guess devices in BUS 1+ cannot
>> be detected.
>>
>> Does Xen pass the resource assignment information through some memory
>> blob to firmware? If yes, we could think about let PciHostBridgeLib pass that
>> information to PciHostBridge driver. If no, we also could let 
>> PciHostBridgeLib
>> collect the information (IO/MEM/BUS resource assignment) and pass that
>> to PciHostBridgeDxe driver.
>>
>> And we need to have a way to tell PciHostBridgeDxe the resource information
>> passed from PciHostBridgeLib is available resource to assign, or already 
>> allocated.
>> Maybe just depends on the PcdPciBusDisableEnumeration. still thinking.
>>
>>
>> Regards,
>> Ray
>>
>> >-Original Message-
>> >From: Gary Lin [mailto:g...@suse.com]
>> >Sent: Tuesday, April 26, 2016 4:40 PM
>> >To: Ni, Ruiyu 
>> >Cc: edk2-de...@lists.01.org; Xen Devel 
>> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>> >
>> >On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
>> >> Gary,
>> >> Maybe the system boots to Shell well but the video isn't initialized 
>> >> properly.
>> >> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
>> >> give me the boot log?
>> >>
>> >Hi Ray,
>> >
>> >I already did and it's how I make the firmware spit the log :-(
>> >
>> >Thanks,
>> >
>> >Gary Lin
>> >
>> >> Regards,
>> >> Ray
>> >>
>> >> From: Gary Lin [mailto:g...@suse.com]
>> >> Sent: Tuesday, April 26, 2016 3:35 PM
>> >> To: Ni, Ruiyu 
>> >> Cc: Anthony PERARD ; edk2-de...@lists.01.org; 
>> >> Xen Devel 
>> >> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>> >>
>> >> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
>> >> >
>> >> >
>> >> > Regards,
>> >> > Ray
>> >> >
>> >> > >-Original Message-
>> >> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> >> > >Anthony PERARD
>> >> > >Sent: Friday, April 22, 2016 10:48 PM
>> >> > >To: edk2-de...@lists.01.org
>> >> > >Cc: Xen Devel mailto:xen-devel@lists.xen.org>>
>> >> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
>> >> > >
>> >> > >Hi,
>> >> > >
>> >> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci 
>> >> > >root
>> >> > >bridge does not finish to initialize and breaks under Xen.
>> >> > >
>> >> > >There are several issue probably due to the use of
>> >> > >PcdPciDisableBusEnumeration=TRUE.
>> >> > >
>> >> > >First one:
>> >> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
>> >> > >Bridge->Mem.Limit <
>> >0x0001ULL
>> >> > >
>> >> > >This patch would fix the first assert:
>> >> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> >> > >index 7fa9019..15ec7a7 100644
>> >> > >--- a/OvmfPkg/PlatformPei/Xen.c
>> >> > >+++ b/OvmfPkg/PlatformPei/Xen.c
>> >> > >@@ -227,5 +227,11 @@ InitializeXen (
>> >> > >
>> >> > >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
>> >> > >
>> >> > >+  // Values from hvmloader
>> >> > >+#define PCI_MEM_END 0xFC00
>> >> > >+#define HVM_BELOW_4G_MMIO_START 0xF000
>> >> > >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
>> >> > >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
>> >> > >+
>> >> > >   return EFI_SUCCESS;
>> >> > > }
>> >> > >
>> >> > >
>> >>

Re: [Xen-devel] [Xen-users] How to install Xen on Fedora 23?

[Jason Long]

Not matter.
I did it too :

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.7-300.fc23.i686
Found initrd image: /boot/initramfs-4.4.7-300.fc23.i686.img
Found linux image: /boot/vmlinuz-4.2.3-300.fc23.i686
Found initrd image: /boot/initramfs-4.2.3-300.fc23.i686.img
Found linux image: /boot/vmlinuz-0-rescue-204e260309794cee901bd6e0b46ace3a
Found initrd image: 
/boot/initramfs-0-rescue-204e260309794cee901bd6e0b46ace3a.img
done


Problem not solved :(



On Wednesday, April 27, 2016 9:06 AM, Konrad Rzeszutek Wilk 
 wrote:
On Tue, Apr 26, 2016 at 03:00:21PM +, Jason Long wrote:
> Hello.
> I installed Fedora 23 x64 on my PC and id below command for installing Xen :
> 
> # cd /etc/yum.repos.d/
> # wget http://fedorapeople.org/groups/virt/...t-preview.repo

Why? No need for that.
> # yum update
> # yum -y install xen xen-hypervisor xen-libs xen-runtime
> # systemctl enable xend.service
> # systemctl enable xendomains.service
> 
> After it I run below command :

You are missing 'grub2-mkconfig -o /boot/grub2/grub.cfg'


> 
> # grep ^menuentry /boot/grub2/grub.cfg | cut -d "'" -f2

> Fedora (4.4.7-300.fc23.i686) 23 (Workstation Edition)
> Fedora (4.2.3-300.fc23.i686) 23 (Workstation Edition)
> Fedora (0-rescue-204e260309794cee901bd6e0b46ace3a) 23 (Workstation Edition)
> 
> But, I can't see any "Fedora, with Xen hypervisor" !!! and when I run "xl 
> info" it show me below error :
> 
> # xl info
> xc: error: Could not obtain handle on privileged command interface (2 = No 
> such file or directory): Internal error
> libxl: error: libxl.c:114:libxl_ctx_alloc: cannot open libxc handle: No such 
> file or directory
> cannot init xl context
> 
> How can I solve it?
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-users mailing list
xen-us...@lists.xen.org
http://lists.xen.org/xen-users 

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

Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

[Juergen Gross]

On 21/04/16 11:30, Stefano Stabellini wrote:
> On Thu, 21 Apr 2016, Juergen Gross wrote:
>> On 20/04/16 15:15, Stefano Stabellini wrote:
>>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
>>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after
>>> probe_8259A(). Use NR_IRQS_LEGACY instead.
>>
>> Would you mind describing the resulting problem?
> 
> This is a good question. The symptom is:
> 
> ata_piix: probe of :00:01.1 failed with error -22
> 
> 
>> With this commit message I'm absolutely not capable to decide whether
>> e.g. the other use of nr_legacy_irqs() in pci_xen_initial_domain() is
>> correct or not.
> 
> I looked at it but I couldn't really test that code because if I try to
> change the number of ioapics in the system using the "noapic" command
> line option (which actually changes the number if ioapics, not lapics),
> I get an error from Linux saying that noapic is not supported when
> running on Xen.
> 
> In my opinion having nr_legacy_irqs() calls in Xen code, which returns
> 0, is like playing with fire. I think it would be safer/saner to replace
> them all with NR_IRQS_LEGACY, simply because reading the code one would
> not expect that all those loops don't actually have any iterations.

I'm quite sure you should change both uses of nr_legacy_irqs() in
pci_xen_initial_domain().

Looking at xen_pcifront_enable_irq() I'm not really sure what is the
correct thing to do.

Adding Konrad as he might have a better insight.


Juergen

> 
> However I didn't make the change because I couldn't test it properly.
> 
> 
>>> Signed-off-by: Stefano Stabellini 
>>>
>>> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
>>> index beac4df..349b8ce 100644
>>> --- a/arch/x86/pci/xen.c
>>> +++ b/arch/x86/pci/xen.c
>>> @@ -491,8 +491,11 @@ int __init pci_xen_initial_domain(void)
>>>  #endif
>>> __acpi_register_gsi = acpi_register_gsi_xen;
>>> __acpi_unregister_gsi = NULL;
>>> -   /* Pre-allocate legacy irqs */
>>> -   for (irq = 0; irq < nr_legacy_irqs(); irq++) {
>>> +   /*
>>> +* Pre-allocate the legacy IRQs.  Use NR_LEGACY_IRQS here
>>> +* because we don't have a PIC and thus nr_legacy_irqs() is zero.
>>> +*/
>>> +   for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
>>> int trigger, polarity;
>>>  
>>> if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
>>>
>>
> 
> 


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

Re: [Xen-devel] [OSSTEST PATCH] crontab: Drop linux-mingo-tip-master linux-next linux-linus

[Juergen Gross]

On 22/04/16 19:08, Roger Pau Monne wrote:
> On Fri, Apr 22, 2016 at 03:54:43PM +0100, Ian Jackson wrote:
>> It appears that no-one is looking at the output.  These have not had a
>> push to the tested output branch for at least 250 days (742 days in
>> the case of linux-linus!) and the reports don't seem to be generating
>> any bugfixing activity.
>>
>> There is a plan to do some Xen testing in Zero-day but even if that
>> doesn't lead to anything we would still be just where we are now.
>>
>> So drop these to save our test bandwith for more useful work.
>>
>> Signed-off-by: Ian Jackson 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Boris Ostrovsky 
>> CC: David Vrabel 
>> CC: Stefano Stabellini 
>> CC: Wei Liu 
>> CC: Roger Pau Monne 
>> CC: Juergen Gross 
>> CC: Anshul Makkar 
> 
> This looks fine to me, but I think I needs to be Acked by the Linux 
> maintainers. FWIW:

Acked-by: Juergen Gross 

> 
> Acked-by: Roger Pau Monné 
> 
>> ---
>>  crontab |5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/crontab b/crontab
>> index 2cfad74..6ddc2b8 100755
>> --- a/crontab
>> +++ b/crontab
>> @@ -7,10 +7,9 @@ MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com
>>  49  1   * * *   cd testing.git && 
>> BRANCHES_ALWAYS=xen-unstable  ./cr-for-branches branches -w 
>> "./cr-daily-branch --real"
>>  0   *   * * *   cd testing.git && 
>> BRANCHES=xen-unstable-smoke   ./cr-for-branches branches -q 
>> "./cr-daily-branch --real"
>>  4-59/30 *   * * *   cd testing.git &&   
>> ./cr-for-branches branches -q "./cr-daily-branch --real"
>> -18  9   * * 1,3,5   cd testing.git && BRANCHES=linux-next   
>> ./cr-for-branches branches -w "./cr-daily-branch --real"
>>  18  9   * * 3,7 cd testing.git && 
>> BRANCHES=xen-unstable-coverity ./cr-for-branches branches -w 
>> "./cr-daily-branch --real"
>> -18  4   * * *   cd testing.git && BRANCHES='linux-linus 
>> linux-mingo-tip-master linux-3.0 libvirt rumpuserxen' ./cr-for-branches 
>> branches -w "./cr-daily-branch --real"
>> -6-59/15 *   * * *   cd testing.git && 
>> EXTRA_BRANCHES='linux-linus linux-3.0 rumpuserxen libvirt' ./cr-for-branches 
>> bisects -w "./cr-try-bisect --real"
>> +18  4   * * *   cd testing.git && BRANCHES='linux-3.0 
>> libvirt rumpuserxen' ./cr-for-branches branches -w "./cr-daily-branch --real"
> 
> Is this linux-3.0 branch actually Linux 3.0? Should we really be testing 
> that? (It's quite old TBH, and it's not even maintained upstream, oldest 
> longterm is 3.2).
> 
> Roger.
> 


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

[Xen-devel] [PATCH] libxl: don't add cache mode for empty drives

[Jim Fehlig]

qemu commit 91a097e7 forbids specifying the cache mode for empty
drives. Attempting to create a domain with an empty qdisk cdrom
results in

qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
   cache=writeback,id=ide-832: Must specify either driver or file

Change libxl to only emit cache mode when a cdrom target is specified.

Signed-off-by: Jim Fehlig 
---
 tools/libxl/libxl_dm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index fd12844..df1207b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1368,11 +1368,11 @@ 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=%s,media=cdrom,cache=writeback,id=ide-%i",
+ "if=ide,index=%d,readonly=%s,media=cdrom,id=ide-%i",
  disk, disks[i].readwrite ? "off" : "on", dev_number);
 
 if (target_path)
-drive = libxl__sprintf(gc, "%s,file=%s,format=%s",
+drive = libxl__sprintf(gc, 
"%s,file=%s,format=%s,cache=writeback",
drive, target_path, format);
 } else {
 /*
-- 
2.1.4


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

Re: [Xen-devel] How to install Xen on Fedora 23?

[Konrad Rzeszutek Wilk]

On Tue, Apr 26, 2016 at 03:00:21PM +, Jason Long wrote:
> Hello.
> I installed Fedora 23 x64 on my PC and id below command for installing Xen :
> 
> # cd /etc/yum.repos.d/
> # wget http://fedorapeople.org/groups/virt/...t-preview.repo

Why? No need for that.
> # yum update
> # yum -y install xen xen-hypervisor xen-libs xen-runtime
> # systemctl enable xend.service
> # systemctl enable xendomains.service
> 
> After it I run below command :

You are missing 'grub2-mkconfig -o /boot/grub2/grub.cfg'

> 
> # grep ^menuentry /boot/grub2/grub.cfg | cut -d "'" -f2

> Fedora (4.4.7-300.fc23.i686) 23 (Workstation Edition)
> Fedora (4.2.3-300.fc23.i686) 23 (Workstation Edition)
> Fedora (0-rescue-204e260309794cee901bd6e0b46ace3a) 23 (Workstation Edition)
> 
> But, I can't see any "Fedora, with Xen hypervisor" !!! and when I run "xl 
> info" it show me below error :
> 
> # xl info
> xc: error: Could not obtain handle on privileged command interface (2 = No 
> such file or directory): Internal error
> libxl: error: libxl.c:114:libxl_ctx_alloc: cannot open libxc handle: No such 
> file or directory
> cannot init xl context
> 
> How can I solve it?
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Tue, Apr 26, 2016 at 09:40:42AM +, Ni, Ruiyu wrote:
> Gary,
> I can reproduce the issue and have debugged to get the reason.
> In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
> PciEnumeratorLight() calls PciRootBridgeIo->Configuration()
> while the Configuration returns EFI_UNSUPPORTED resulting
> the PciBus driver exits earlier.
> You could try to manually set MinBus to 0 and MaxBus to 0xFF.
> 
Do you mean to set MinBus and MaxBus in PciGetBusRange() ?
Should I also keep the EFI_UNSUPPORTED code in Configuration() ?

> The second change you need to make is in PciIo.c:
> Change GetMmioAddressTranslationOffset() to return 0 instead
> of -1 when error occurs
> 

Should I also remove "ASSERT (FALSE);" ?

Cheers,

Gary Lin

> With the above 2 changes, can you check whether the system can
> boot?
> 
> If it can boot, then we need to think about what the proper fix is.
> For OVMF above Xen, the PCI resources are assigned by Xen other than
> PciBus driver. So PciRootBridgeIo->Configuration() doesn't know
> the resource assignment information.
> With old PciHostBridge driver, the Configuration() returns BUS resource
> descriptor with MinBus = MaxBus = 0 (default value), so that the PciBus
> driver can detect all devices in BUS 0, but I guess devices in BUS 1+ cannot
> be detected.
> 
> Does Xen pass the resource assignment information through some memory
> blob to firmware? If yes, we could think about let PciHostBridgeLib pass that
> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib
> collect the information (IO/MEM/BUS resource assignment) and pass that
> to PciHostBridgeDxe driver.
> 
> And we need to have a way to tell PciHostBridgeDxe the resource information
> passed from PciHostBridgeLib is available resource to assign, or already 
> allocated.
> Maybe just depends on the PcdPciBusDisableEnumeration. still thinking.
> 
> 
> Regards,
> Ray
> 
> >-Original Message-
> >From: Gary Lin [mailto:g...@suse.com]
> >Sent: Tuesday, April 26, 2016 4:40 PM
> >To: Ni, Ruiyu 
> >Cc: edk2-de...@lists.01.org; Xen Devel 
> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >On Tue, Apr 26, 2016 at 08:19:49AM +, Ni, Ruiyu wrote:
> >> Gary,
> >> Maybe the system boots to Shell well but the video isn't initialized 
> >> properly.
> >> Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and
> >> give me the boot log?
> >>
> >Hi Ray,
> >
> >I already did and it's how I make the firmware spit the log :-(
> >
> >Thanks,
> >
> >Gary Lin
> >
> >> Regards,
> >> Ray
> >>
> >> From: Gary Lin [mailto:g...@suse.com]
> >> Sent: Tuesday, April 26, 2016 3:35 PM
> >> To: Ni, Ruiyu 
> >> Cc: Anthony PERARD ; edk2-de...@lists.01.org; 
> >> Xen Devel 
> >> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >>
> >> On Tue, Apr 26, 2016 at 06:43:56AM +, Ni, Ruiyu wrote:
> >> >
> >> >
> >> > Regards,
> >> > Ray
> >> >
> >> > >-Original Message-
> >> > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> >> > >Anthony PERARD
> >> > >Sent: Friday, April 22, 2016 10:48 PM
> >> > >To: edk2-de...@lists.01.org
> >> > >Cc: Xen Devel mailto:xen-devel@lists.xen.org>>
> >> > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation)
> >> > >
> >> > >Hi,
> >> > >
> >> > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci 
> >> > >root
> >> > >bridge does not finish to initialize and breaks under Xen.
> >> > >
> >> > >There are several issue probably due to the use of
> >> > >PcdPciDisableBusEnumeration=TRUE.
> >> > >
> >> > >First one:
> >> > >ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): 
> >> > >Bridge->Mem.Limit <
> >0x0001ULL
> >> > >
> >> > >This patch would fix the first assert:
> >> > >diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
> >> > >index 7fa9019..15ec7a7 100644
> >> > >--- a/OvmfPkg/PlatformPei/Xen.c
> >> > >+++ b/OvmfPkg/PlatformPei/Xen.c
> >> > >@@ -227,5 +227,11 @@ InitializeXen (
> >> > >
> >> > >   PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
> >> > >
> >> > >+  // Values from hvmloader
> >> > >+#define PCI_MEM_END 0xFC00
> >> > >+#define HVM_BELOW_4G_MMIO_START 0xF000
> >> > >+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
> >> > >+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
> >> > >+
> >> > >   return EFI_SUCCESS;
> >> > > }
> >> > >
> >> > >
> >> > >But that not enough, next assert is:
> >> > >ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): 
> >> > >RootBridge != ((void *) 0)
> >> > >
> >> > >I have worked around this one with the following patch. That would
> >> > >correspond to how the former implementation in OvmfPkg was initializing 
> >> > >the
> >> > >struct. Maybe a better way would be to fill ResAllocated under Xen,
> >> > >somehow. Under Xen, the ResAllocNode status is not allocated, so no
> >> > >Descriptor a

[Xen-devel] [xen-unstable test] 92842: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3)   broken pass in 92791
 test-armhf-armhf-libvirt  6 xen-boot   fail in 92791 pass in 92842
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail pass in 92791

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 92791 like 
92651
 build-i386-rumpuserxen6 xen-buildfail   like 92651
 build-amd64-rumpuserxen   6 xen-buildfail   like 92651
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92651
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92651
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92651
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92651

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

version targeted for testing:
 xen  488c2a860a6d7eb69f4acfeb349b457aaba76dfa
baseline version:
 xen  e0ec0a717d882ff0c0935b4893792d6aa95df3ef

Last test of basis92651  2016-04-25 02:00:45 Z2 days
Failing since 92720  2016-04-25 15:15:39 Z1 days3 attempts
Testing same since92791  2016-04-26 03:43:14 Z1 days2 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Doug Goldstein 
  Fu Wei 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v9 10/27] xsplice: Add helper elf routines

[Konrad Rzeszutek Wilk]

> > +static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
> > +{
..snip..
> > +/* e_shoff and e_shnum overflow checks are done in 
> > xsplice_header_check. */
> > +delta = elf->hdr->e_shoff + elf->hdr->e_shnum * elf->hdr->e_shentsize;
> 
> The added comment just helps make obvious that the overflow I
> believe Andrew was worried about is still not being taken care of:
> All xsplice_header_check() does is range check the two values
> mentioned in the comment. But I agree that a proper range check
> (at once eliminating overflow concerns for the arithmetic here)
> would better live there (and also see there).

..snip..
> > +static int xsplice_header_check(const struct xsplice_elf *elf)
> > +{ 
..snip..
> > +if ( elf->hdr->e_shnum > 64 )
> > +{
> > +dprintk(XENLOG_ERR, XSPLICE "%s: Too many (%u) sections!\n",
> > +elf->name, elf->hdr->e_shnum);
> > +return -EOPNOTSUPP;
> > +}
> > +
> > +if ( elf->hdr->e_shoff > ULONG_MAX )
> 
> Why not ">= elf->len" (and I see it was almost that way in v8.1)?

I misunderstood your comment. You mentioned to me that we have
an boundary check here (when it was against elf->len) and that you
wanted an overflow - so I replaced it - while you meant - in addition to.

But adding in both:

elf->hdr->e_shoff >= ULONG_MAX || elf->hdr->e_shoff >= elf->len

feels unneccessary. And the boundary check is more imporant.
I added both in the code.


> And then followed (further down) by another check taking
> elf->hdr->e_shnum * elf->hdr->e_shentsize into account (of
> course as things stand now, elf->hdr->e_shentsize can also be
> arbitrarily large, so this would need to be suitably structured
> - e.g. "(elf->len - elf->hdr->e_shoff) / elf->hdr->e_shentsize <
> elf->hdr->e_shnum").

Ah, so that is how you want to check for e_shnum!

Here is the updated patch:


From eb90312d4ff66c17fad2d4cd5379974fc4c9f2f6 Mon Sep 17 00:00:00 2001
From: Ross Lagerwall 
Date: Fri, 19 Feb 2016 14:37:17 -0500
Subject: [PATCH] xsplice: Add helper elf routines

Add Elf routines and data structures in preparation for loading an
xSplice payload.

We make an assumption that the max number of sections an ELF payload
can have is 64. We can in future make this be dependent on the
names of the sections and verifying against a list, but for right now
this suffices.

Also we a whole lot of checks to make sure that the ELF payload
file is not corrupted nor that the offsets point past the file.

For most of the checks we print an message if the hypervisor is built
with debug enabled.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Ian Jackson 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v2: - With the #define ELFSIZE in the ARM file we can use the common
 #defines instead of using #ifdef CONFIG_ARM_32. Moved to another
patch.
- Add checks for ELF file.
- Add name to be printed.
- Add len for easier ELF checks.
- Expand on the checks. Add macro.
v3: Remove the return_ macro
  - Add return_ macro back but make it depend on debug=y
  - Per Andrew review: add local variable. Fix memory leak in
elf_resolve_sections, Remove macro and use dprintk. Fix alignment.
Use void* instead of uint8_t to handle raw payload.
v4 - Fix memory leak in elf_get_sym
  - Add XSPLICE to printk/dprintk
v5: Sprinkle newlines.
v6: Squash the ELF header checks from 'xsplice: Implement payload loading' here,
Do better job at checking string sections and the users of them (sh_size),
Use XSPLICE as a string literal,
Move some checks outside the loop,
Make sure that SHT_STRTAB are really what they say
Sprinkle consts.
v7:
Check sh_entsize and sh_offset.
Added Andrew's Reviewed-by and Ian's Acked-by
Redo check on sh_entsize to not be !=
v8: Make all the dprintk(XENLOG_DEBUG be XENLOG_ERR
v9: Changed elf_verify_strtab to use const char and return EINVAL.
Remove 'if ( !delta )' check in elf_resolve_sections
Remove stale comments.
Fixed one off check against  sh_link.
Document boundary checks against shstrtab and symtab.
Fixed return codes in xsplice_header_check.
Add check for sections to not be within ELF header.
Added overflow check for e_shoff in xsplice_header_check.
Moved XSPLICE macro by four tabs.
Make ->sym be const.
v10:
  - Change the check against 64 to be against SHN_LORESERVE
  - Remove Reviewed-by
  - In elf_resolve_sections skip delta check if SHT_NOBITS is set in
second conditional.
  - In elf_get_sym use symtab_sec->sec->sh_entsize to access
Elf_Sym symbols and also make it a const. Also
fix boundary check against .strtab and make assigment of
sym[i].name more natural.
  - In xsplice_header_check add comment about EI_CLASS and e_flags
being platform specific. Check against e_version and EI_VERSION.
Also reinstate elf->hdr->e_shoff >= elf->len  check. Add Jan's check against
   

[Xen-devel] [xen-4.3-testing test] 92882: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  5 xen-install fail pass in 92778

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-libvirt  6 xen-boot  fail in 92778 never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass

version targeted for testing:
 xen  c04846eeb3d96cf670dc5894b66f3f6e61c2531d
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-

Re: [Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

[Konrad Rzeszutek Wilk]

. snip..
> 
> Thinking about it again, even more stack conserving would be a
> bitmap...

Heheh
> 
> > +static int apply_payload(struct payload *data)
> > +{
> > +unsigned int i;
> > +
> > +printk(XENLOG_INFO XSPLICE "%s: Applying %u functions\n",
> > +data->name, data->nfuncs);
> > +
> > +arch_xsplice_patching_enter();
> > +
> > +for ( i = 0; i < data->nfuncs; i++ )
> > +arch_xsplice_apply_jmp(&data->funcs[i]);
> > +
> > +arch_xsplice_patching_leave();
> > +
> > +list_add_tail_rcu(&data->applied_list, &applied_list);
> 
> Neither in the comment earlier on nor here it becomes clear that this
> is more of an abuse than a use of RCU.

I added more comments and..
> 
> > +struct xsplice_patch_func {
> > +const char *name;   /* Name of function to be patched. */
> > +void *new_addr;
> > +void *old_addr;
> > +uint32_t new_size;
> > +uint32_t old_size;
> > +uint8_t version;/* MUST be XSPLICE_PAYLOAD_VERSION. */
> > +uint8_t opaque[31]; /* MUST be zero filled. */
> 
> I don't see the zero filling being a requirement, nor it being enforced.

.. removed this.

From adeadf8babcc5ef6d512cdc28899b4d1de34c60e Mon Sep 17 00:00:00 2001
From: Ross Lagerwall 
Date: Thu, 21 Apr 2016 06:14:29 -0400
Subject: [PATCH] xsplice: Implement support for applying/reverting/replacing
 patches.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Implement support for the apply, revert and replace actions.

To perform and action on a payload, the hypercall sets up a data
structure to schedule the work.  A hook is added in the reset_stack_and_jump
to check for work and execute it if needed (specifically we check an
per-cpu flag to make this as quick as possible).

In this way, patches can be applied with all CPUs idle and without
stacks.  The first CPU to run check_for_xsplice_work() becomes the
master and triggers a reschedule softirq to trigger all the other CPUs
to enter check_for_xsplice_work() with no stack.  Once all CPUs
have rendezvoused, all CPUs disable their IRQs and NMIs are ignored.
The system is then quiscient and the master performs the action.
After this, all CPUs enable IRQs and NMIs are re-enabled.

Note that it is unsafe to patch do_nmi and the xSplice internal functions.
Patching functions on NMI/MCE path is liable to end in disaster on x86.
This is not addressed in this patch and is mentioned in the
design doc as a further TODO.

The action to perform is one of:
- APPLY: For each function in the module, store the first arch-specific
  number bytes of the old function and replace it with a jump to the
  new function. (on x86 it is 5 bytes, on ARM it will likey be 4 bytes).
- REVERT: Copy the previously stored bytes into the first arch-specific
  number of bytes of the old function (again, 5 bytes on x86).
- REPLACE: Revert each applied module and then apply the new module.

To prevent a deadlock with any other barrier in the system, the master
will wait for up to 30ms before timing out.
Measurements found that the patch application to take about 100 μs on a
72 CPU system, whether idle or fully loaded.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Julien Grall 

--
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2: - Pluck the 'struct xsplice_patch_func' in this patch.
- Modify code per review comments.
- Add more data in the keyboard handler.
- Redo the patching code, split it in functions.
v3: - Add return_ macro for debug builds.
- Move s/payload_list_lock/payload_list/ to earlier patch
- Remove const and use ELF types for xsplice_patch_func
 - Add check routine to do simple sanity checks for various
  sections.
- s/%p/PRIx64/ as ARM builds complain.
- Move code around. Add more dprintk. Add XSPLICE in front of all
  printks/dprintk.
  Put the NMIs back if we fail patching.
  Add per-cpu to lessen contention for global structure.
  Extract from xsplice_do_single patching code into xsplice_do_action
  Squash xsplice_do_single and check_for_xsplice_work together to
  have all rendezvous in one place.
  Made XSPLICE_ACTION_REPLACE work again (wrong list iterator)
  s/find_special_sections/prepare_payload/
  Use list_del_init and INIT_LIST_HEAD for applied_list
v4:
   - Add comment, adjust spacing for "Timed out on CPU semaphore"
   - Added CR0.WP manipulations when altering the .text of hypervisor.
   - Added fix from Andrew for CR0.WP manipulation.
v5: - Made xsplice_patch_func use uintXX_t instead of ELF_ types to easy
  making it work under ARM (32bit). Add more BUILD-BUG-ON checks.
- Add more BUILD_ON checks. Sprinkle newlines.
v6: Rebase on "arm/x86: Alter nmi_callback_t typedef"
   - Drop the recursive spinlock usage.
   - Move NMI callbacks in arch

Re: [Xen-devel] [PATCH v9 16/27] x86, xsplice: Print payload's symbol name and payload name in backtraces

[Konrad Rzeszutek Wilk]

> >> When text_addr is void *, how is this calculation wrong then?
> > 
> > I'm sorry, ignore that. I temporarily forgot how void* arithmetic is 
> > defined for GCC.
> > 
> > The other two points are still valid and may result in incorrect 
> > backtraces with > 1 payload loaded.
> 
> Of course.

So it would look like this then:

From affca85da4d57c466cc3a603afa4d57fea7ed092 Mon Sep 17 00:00:00 2001
From: Ross Lagerwall 
Date: Fri, 22 Apr 2016 11:16:36 -0400
Subject: [PATCH] x86, xsplice: Print payload's symbol name and payload name in
 backtraces

Naturally the backtrace is presented when an instruction
hits an bug_frame or %p is used.

The payloads do not support bug_frames yet - however the functions
the payloads call could hit an BUG() or WARN().

The traps.c has logic to scan for it this - and eventually it will
find the correct bug_frame and the walk the stack using %p to print
the backtrace. For %p and symbols to print a string -  the
'is_active_kernel_text' is consulted which uses an 'struct virtual_region'.

Therefore we register our start->end addresses so that
'is_active_kernel_text' will include our payload address.

We also register our symbol lookup table function so that it can
scan the list of payloads and retrieve the correct name.

Lastly we change vsprintf to take into account s and namebuf.
For core code they are the same, but for payloads they are different.
This gets us:

Xen call trace:
   [] revert_hook+0x31/0x35 [xen_hello_world]
   [] xsplice.c#revert_payload+0x86/0xc6
   [] check_for_xsplice_work+0x233/0x3cd
   [] domain.c#continue_idle_domain+0x9/0x1f

Which is great if payloads have similar or same symbol names.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v2: Add missing full stop.
v3: s/module/payload/
v4: Expand comment and include registration of 'virtual_region'
Redo the vsprintf handling of payload name.
Drop the ->skip function
v6: Add comment explaining the purpose behind the strcmp.
Redid per Jan's review.
v7: Add Andrew's Review-by
Drop the strcmp and just do pointer checks.
v9: Do pointer comparison on vsprintf by itself, no need for intermediate
payload bool_t
Add const in xsplice_symbols_lookup
Make 'best' in xsplice_symbols_lookup be unsigned int.
Use an RCU list for iterating the applied_list. Define the RCU lock.
v10:
In xsplice_symbols_lookup use || instead of && when skipping.
Also in xsplice_symbols_lookup use ->text_size instead of ->pages.
---
---
 xen/common/vsprintf.c | 12 +
 xen/common/xsplice.c  | 69 ---
 xen/include/xen/xsplice.h |  1 +
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 18d2634..70e1edf 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -354,6 +355,17 @@ static char *pointer(char *str, char *end, const char 
**fmt_ptr,
 str = number(str, end, sym_size, 16, -1, -1, SPECIAL);
 }
 
+/*
+ * namebuf contents and s for core hypervisor are same but for xSplice
+ * payloads they differ (namebuf contains the name of the payload).
+ */
+if ( namebuf != s )
+{
+str = string(str, end, " [", -1, -1, 0);
+str = string(str, end, namebuf, -1, -1, 0);
+str = string(str, end, "]", -1, -1, 0);
+}
+
 return str;
 }
 
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 85af98a..188b850 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -14,7 +14,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,10 +33,9 @@ static LIST_HEAD(payload_list);
 
 /*
  * Patches which have been applied. Need RCU in case we crash (and then
- * traps code would iterate via applied_list) when adding entries on the list.
- *
- * Note: There are no 'rcu_applied_lock' as we don't iterate yet the list.
+ * traps code would iterate via applied_list) when adding entries onthe list.
  */
+static DEFINE_RCU_READ_LOCK(rcu_applied_lock);
 static LIST_HEAD(applied_list);
 
 static unsigned int payload_cnt;
@@ -56,6 +57,8 @@ struct payload {
 unsigned int nfuncs; /* Nr of functions to patch. */
 const struct xsplice_symbol *symtab; /* All symbols. */
 const char *strtab;  /* Pointer to .strtab. */
+struct virtual_region region;/* symbol, bug.frame patching and
+exception table (x86). */
 unsigned int nsyms;  /* Nr of entries in .strtab and 
symbols. */
 char name[XEN_XSPLICE_NAME_SIZE];/* Name of it. */
 };
@@ -139,6 +142,55 @@ void *xsplice_symbols_lookup_by_name(const char *s

Re: [Xen-devel] [PATCH v9 11/27] xsplice: Implement payload loading

[Konrad Rzeszutek Wilk]

> > +static int move_payload(struct payload *payload, struct xsplice_elf *elf)
> > +{
..snip..
> > +for ( i = 1; i < elf->hdr->e_shnum; i++ )
> > +{
> > +if ( elf->sec[i].sec->sh_flags & SHF_ALLOC )
> > +{
> > +uint8_t *buf;
> 
> Perhaps void * again? And missing a blank line afterwards.
> 
> > +if ( (elf->sec[i].sec->sh_flags & SHF_EXECINSTR) )
> > +buf = text_buf;
> > +else if ( (elf->sec[i].sec->sh_flags & SHF_WRITE) )
> > +buf = rw_buf;
> > + else
> 
> The indentation here is still one off.

I am not seeing it. I deleted the line and added it back using
spaces just in case. But I really don't see the indentation isse
you are seeing?

Here is what the patch looks like with the changes (minus the
possiblility of making Elf_Sym an const and casting it ..):

From 4b190a9d9fe738138416d9f501ac746ea9db2512 Mon Sep 17 00:00:00 2001
From: Ross Lagerwall 
Date: Tue, 26 Apr 2016 13:52:48 -0400
Subject: [PATCH] xsplice: Implement payload loading

Add support for loading xsplice payloads. This is somewhat similar to
the Linux kernel module loader, implementing the following steps:
- Verify the elf file.
- Parse the elf file.
- Allocate a region of memory mapped within a free area of
  [xen_virt_end, XEN_VIRT_END].
- Copy allocated sections into the new region. Split them in three
  regions - .text, .data, and .rodata. MUST have at least .text.
- Resolve section symbols. All other symbols must be absolute addresses.
  (Note that patch titled "xsplice,symbols: Implement symbol name resolution
   on address" implements that)
- Perform relocations.
- Secure the the regions (.text,.data,.rodata) with proper permissions.

We capitalize on the vmalloc callback API (see patch titled:
"rm/x86/vmap: Add v[z|m]alloc_xen, and vm_init_type") to allocate
a region of memory within the [xen_virt_end, XEN_VIRT_END] for the code.

We also use the "x86/mm: Introduce modify_xen_mappings()"
to change the virtual address page-table permissions.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Julien Grall 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2: - Change the 'xsplice_patch_func' structure layout/size.
- Add more error checking. Fix memory leak.
- Move elf_resolve and elf_perform relocs in elf file.
- Print the payload address and pages in keyhandler.
v3:
- Make it build under ARM
- Build it without using the return_ macro.
- Add fixes from Ross.
- Add the _return macro back - but only use it during debug builds.
- Remove the macro, prefix arch_ on arch specific calls.
v4:
- Move alloc_payload to arch specific file.
- Use void* instead of uint8_t, use const
- Add copyrights
- Unroll the vmap code to add ASSERT. Change while to not incur
  potential long error loop
   - Use vmalloc/vfree cb APIs
   - Secure .text pages to be RX instead of RWX.
v5:
  - Fix allocation of virtual addresses only allowing one page to be allocated.
  - Create .text, .data, and .rodata regions with different permissions.
  - Make the find_space_t not a typedef to pointer to a function.
  - Allocate memory in here.
v6: Drop parentheses on typedefs.
  - s/an xSplice/a xSplice/
  - Rebase on "vmap: Add vmalloc_cb"
  - Rebase on "vmap: Add vmalloc_type and vm_init_type"
  - s/uint8_t/void/ on load_addr
  - Set xsplice_elf on stack without using memset.
v7:
  - Changed the check on delta = elf->hdr->e_shoff + elf->hdr->e_shnum * 
elf->hdr->e_shentsize;
The sections can be right at the back of the file (different linker!), so 
the failing conditional
for 'if (delta >= elf->len)' is incorrect and should have been '>'.
  - Changed dprintk(XENLOG_DEBUG to XENLOG_ERR, then back to DEBUG. Converted
some of the printk to dprintk.
  - Rebase on " arm/x86/vmap: Add vmalloc_xen, vfree_xen and vm_init_type"
  - Changed some of the printk XENLOG_ERR to XENLOG_DEBUG
  - Check the idx in the relocation to make sure it is within bounds and
implemented.
  - Use "x86/mm: Introduce modify_xen_mappings()"
  - Introduce PRIxElfAddr
  - Check for overflow in R_X86_64_PC32
  - Return -EOPNOTSUPP if we don't support types in ELF64_R_TYPE
v8:
  - Change dprintk and printk XENLOG_DEBUG to XENLOG_ERR
  - Convert four of the printks in dprintk.
v9:
  - Rebase on different spinlock usage in xsplice_upload.
  - Do proper bound and overflow checking.
  - Added 'const' on [text,ro,rw]_addr.
  - Made 'calc_section' and 'move_payload' use an dynamically
allocated array for computed offsets instead of modifying sh_entsize.
  - Remove arch_xsplice_[alloc_payload|free] and use vzalloc_xen and
vfree.
  - Collapse for loop in move_payload.
  - Move xsplice.o in Makefile
  - Add more checks in arch_xsplice_perform_rela (r_offset and
 sh_size % sh_entsize)
  - Use int32_t and int64_t in arch_xsplice_perform_rela.
  - Tighten the li

[Xen-devel] [ovmf test] 92876: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 0b448dd8b27c9efac370576b18edada004ab560a
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  140 days
Failing since 65593  2015-12-08 23:44:51 Z  140 days  181 attempts
Testing same since92876  2016-04-26 20:45:09 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v9 08/27] arm/x86/vmap: Add v[z|m]alloc_xen and vm_init_type

[Konrad Rzeszutek Wilk]

> With vm_alloc() getting removed, vm_free() should get removed
> here too. And with that, vm_alloc_type() and vm_free_type() can
> then just become vm_alloc() and vm_free() respectively (as static
> internal functions).

Please take a look at this inline one:

From 1c133365d98a02c8f5131cdcde11960623fa247a Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 26 Apr 2016 14:03:06 -0400
Subject: [PATCH] arm/x86/vmap: Add v[z|m]alloc_xen and vm_init_type

For those users who want to use the virtual addresses that
are in the hypervisor's code/data region address space -
these three new functions allow that.

Implementation wise the vmap API keeps track of two virtual
address regions now:
 a) VMAP_VIRT_START
 b) Any provided virtual address space (need start and end).

The a) one is the default one and the existing behavior
for users of vmalloc, vmap, etc is the same.

If however one wishes to use the b) one only has to use
the vm_init_type to initialize and the v[m|z]alloc_xen to utilize
it (vfree and vunmap are capable of searching both address spaces).

This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86) while not having to deal with the allocation of
pages.

For example of users, see patch titled "xsplice: Implement payload
loading", where we parse the payload's ELF relocations - which
is defined to be signed 32-bit (on x86) (max displacement hence
is 2GB virtual space, ARM32 is 128MB). The displacement of the
hypervisor virtual addresses to the vmalloc (on x86)
is more than 32-bits - which means that ELF relocations would
truncate the 34 and 33th bit. Hence this alternate API.

We also add add extra checks in case the b) range has not been
initialized.

Part of this patch also removes 'vm_alloc' and 'vm_free'
decleration as we do not have any users of it.

Signed-off-by: Konrad Rzeszutek Wilk 
Suggested-by: Jan Beulich 
Acked-by: Julien Grall  [ARM]

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v4: New patch.
v5: Update per Jan's comments.
v6: Drop the stray parentheses on typedefs.
Ditch the vunmap callback. Stash away the virtual addresses in lists.
Ditch the vmap callback. Just provide virtual address.
Ditch the vmalloc_range. Require users of alternative virtual address
to call vmap_init_type first.
v7: Don't expose the vmalloc_type and such. Instead provide an wrapper
called vmalloc_xen for those.
Rename the enum, change one of the names.
Moved the vunmap_type around in c file so we don't have to declare
it in the header.
v9: Remove the vunmap_xen, removed vm_alloc from header.
Add vzalloc_xen
v10:
Properly ASSERT on ranges
Make vm_free and vunmap automatically detect the right va space.
Remove from header vm_free. Rename vm_alloc_type and vm_free_type
to  vm_alloc and vm_free respectively.
---
 xen/arch/arm/kernel.c  |   2 +-
 xen/arch/arm/mm.c  |   2 +-
 xen/arch/x86/mm.c  |   2 +-
 xen/common/vmap.c  | 212 +++--
 xen/drivers/acpi/osl.c |   2 +-
 xen/include/xen/vmap.h |  22 +++--
 6 files changed, 156 insertions(+), 86 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 61808ac..9871bd9 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -299,7 +299,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
 return -ENOMEM;
 }
 mfn = _mfn(page_to_mfn(pages));
-output = __vmap(&mfn, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR);
+output = __vmap(&mfn, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR, 
VMAP_DEFAULT);
 
 rc = perform_gunzip(output, input, size);
 clean_dcache_va_range(output, output_size);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7065c3e..94ea054 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -807,7 +807,7 @@ void *ioremap_attr(paddr_t pa, size_t len, unsigned int 
attributes)
 mfn_t mfn = _mfn(PFN_DOWN(pa));
 unsigned int offs = pa & (PAGE_SIZE - 1);
 unsigned int nr = PFN_UP(offs + len);
-void *ptr = __vmap(&mfn, nr, 1, 1, attributes);
+void *ptr = __vmap(&mfn, nr, 1, 1, attributes, VMAP_DEFAULT);
 
 if ( ptr == NULL )
 return NULL;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a42097f..2bb920b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6179,7 +6179,7 @@ void __iomem *ioremap(paddr_t pa, size_t len)
 unsigned int offs = pa & (PAGE_SIZE - 1);
 unsigned int nr = PFN_UP(offs + len);
 
-va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
+va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE, VMAP_DEFAULT) + 
offs;
 }
 
 return (void __force __iomem *)va;
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 134eda0..9c8782c 100644
--- a/xen/common/vmap.c
+++ 

Re: [Xen-devel] [PATCH v9 10/27] xsplice: Add helper elf routines

[Konrad Rzeszutek Wilk]

> > +static int xsplice_header_check(const struct xsplice_elf *elf)
> > +{
> > +const Elf_Ehdr *hdr = elf->hdr;
> > +
> > +if ( sizeof(*elf->hdr) > elf->len )
> > +{
> > +dprintk(XENLOG_ERR, XSPLICE "%s: Section header is bigger than 
> > payload!\n",
> > +elf->name);
> > +return -EINVAL;
> > +}
> > +
> > +if ( !IS_ELF(*hdr) )
> > +{
> > +dprintk(XENLOG_ERR, XSPLICE "%s: Not an ELF payload!\n", 
> > elf->name);
> > +return -EINVAL;
> > +}
> > +
> > +if ( hdr->e_ident[EI_CLASS] != ELFCLASS64 ||
> > + hdr->e_ident[EI_DATA] != ELFDATA2LSB ||
> > + hdr->e_ident[EI_OSABI] != ELFOSABI_SYSV ||
> 
> What about EI_VERSION and EI_ABIVERSION, btw?

As I did some prototype on ARM32 I realized that the EI_CLASS is wrong
in common code (as ELFCLASS32 is what ARM32 has). And the EI_ABIVERSION
too.

So EI_CLASS check moves to arch/x86/xsplice.c (and not in this
patch but in xsplice: Implement payload loading).


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

Re: [Xen-devel] [PATCH v9 11/27] xsplice: Implement payload loading

[Konrad Rzeszutek Wilk]

> > +static int move_payload(struct payload *payload, struct xsplice_elf *elf)
> > +{
.. snip..
> > +/* Compute size of different regions. */
> > +for ( i = 1; i < elf->hdr->e_shnum; i++ )
> > +{
> > +if ( (elf->sec[i].sec->sh_flags & (SHF_ALLOC|SHF_EXECINSTR)) ==
> > + (SHF_ALLOC|SHF_EXECINSTR) )
> > +calc_section(&elf->sec[i], &payload->text_size, &offset[i]);
> 
> This silently accepts writable text sections, yet the portion of the
> memory this gets placed in will be mapped RX.

I am not sure I follow. We only accept if sh_flags have AX. Not WAX?
How am I accepting writable text sections?
> 
> > +else if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
> > +  !(elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
> > +  (elf->sec[i].sec->sh_flags & SHF_WRITE) )
> > +calc_section(&elf->sec[i], &payload->rw_size, &offset[i]);
> > +else if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
> > +  !(elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
> > +  !(elf->sec[i].sec->sh_flags & SHF_WRITE) )
> > +calc_section(&elf->sec[i], &payload->ro_size, &offset[i]);
> > +else if ( !elf->sec[i].sec->sh_flags ||
> > +  (elf->sec[i].sec->sh_flags & SHF_EXECINSTR) ||
> > +  (elf->sec[i].sec->sh_flags & SHF_MASKPROC) )
> > +/* Do nothing.*/;
> > +else if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
> > +  (elf->sec[i].sec->sh_type == SHT_NOBITS) )
> > +{
> > +dprintk(XENLOG_DEBUG, XSPLICE "%s: Not supporting %s 
> > section!\n",
> > +elf->name, elf->sec[i].name);
> > +rc = -EOPNOTSUPP;
> > +goto out;
> > +}
> 
> I saw this in the changelog, but I don't really understand these last
> two conditionals. Wouldn't you want to bail on _any_ sections which

The first (/Do nothing/) is for sections such as .rela.* (which we can
ditch after we are done), .symtab, .strtab (for which in later patches in
build_symbol_table construct a copy), and:

[ 1] .note.gnu.build-i NOTE   0040
   0024     A   0 0 4

which value we just copy in struct payload->id.
(also in later patch).
> have SHF_ALLOC set but don't get mapped to one of the three
> blocks? And wouldn't you (silently) ignore any sections with SHF_ALLOC
> clear?

Correct, such as:
 [29] .shstrtab STRTAB     02fe
   0143     0 0 1

I've update the comments to be more clear.

..snip..
> > +int xsplice_elf_resolve_symbols(struct xsplice_elf *elf)
> > +{
> > +unsigned int i;
> > +int rc = 0;
> > +
> > +ASSERT(elf->sym);
> > +
> > +for ( i = 1; i < elf->nsym; i++ )
> > +{
> > +unsigned int idx = elf->sym[i].sym->st_shndx;
> > +Elf_Sym *sym = (Elf_Sym *)elf->sym[i].sym;
> 
> Well, I admit that this is the more straightforward solution, but it
> opens up all of what sym points to for writing. I.e. I'd have
> considered it much better to really only do the casting away of
> const in the one spot where you need it (see below).

OK. That may become a bit cumbersome. We would have in the later
patches (xsplice,symbols: Implement symbol name resolution on addres)
the SHN_UNDEF doing symbol lookup. And that one tries to set
sym->st_value twice.

I can certainly cast it twice there, and then once in the default
case if you would like.

> 
> > +switch ( idx )
> > +{
> > +case SHN_COMMON:
> > +dprintk(XENLOG_ERR, XSPLICE "%s: Unexpected common symbol: 
> > %s\n",
> > +elf->name, elf->sym[i].name);
> > +rc = -EINVAL;
> > +break;
> > +
> > +case SHN_UNDEF:
> > +dprintk(XENLOG_ERR, XSPLICE "%s: Unknown symbol: %s\n",
> > +elf->name, elf->sym[i].name);
> > +rc = -ENOENT;
> > +break;
..snip..
> > +default:

..snip..
> > +
> > +sym->st_value += (unsigned long)elf->sec[idx].load_addr;
> 
> *( *)&sym->st_value += ...

Right, so I can cast it to a non-const and write to it. Keep in mind
that in this patch it is only one place, but in further I would have
to do this twice.

What is your preference?
> 

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Meng Xu]

>
>> > 4. A work-conserving mode
>> I think we need to consider the item 4 carefully. Work-conserving
>> mode
>> is not a must for real-time schedulers and it is not the main
>> purpose/goal of the RTDS scheduler.
>>
> It's indeed not a must for real-time schedulers. In fact, it's only
> important if one wants the system to be overall usable, when using a
> real-time scheduler. :-P
>
> Also, I may be wrong but it should not be too hard to implement...
> I.e., a win-win. :-)

I'm thinking if we want to implement work-conserving policy in RTDS,
how should we allocate the unused resource to domains. Should this
allocation be promotional to the budget/period each domain is
configured with?
I guess the complexity totally depends on which work-conserving
algorithm we want to encode into RTDS.

For example, we can have priority bands that when a VCPU depletes its
budget, it will goes to the lower priority band. The VCPU on a lower
priority band will not be scheduled until all VCPUs in a higher
priority band are scheduled.
This policy seems easy to incorporate into the RTDS. (But I have to
think harder to make sure there is not catch :-) )

Best,

Meng

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

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Meng Xu]

On Tue, Apr 26, 2016 at 6:49 PM, Dario Faggioli
 wrote:
> On Tue, 2016-04-26 at 14:38 -0400, Meng Xu wrote:
>> > So, yes, the scheduler is now feature complete (with the per-vcpu
>> > parameters) and adheres to a much more sensible and scalable design
>> > (event driven). Yet, these features have been merged very recently,
>> > therefore, when you say "tested", I'm not so sure I agree. In fact,
>> > we
>> > do test it on OSSTest, but only in a couple of tests. The
>> > combination
>> > of these two things make me think that we should allow for at least
>> > another development cycle, before considering switching.
>> I see. So should we mark it as Completed for Xen 4.7? or should we
>> wait until Xen 4.8 to mark it as Completed if nothing bad happens to
>> the scheduler?
>>
> We should define the criteria. :-)
>
> In any case, not earlier than 4.8, IMO.
>
>> > And even in that case, I wonder how we should handle such a
>> > situation... I was thinking of adding a work-conserving mode, what
>> > do
>> > you think?
>> Hmm, I can get why work-conserving mode is necessary and useful. I'm
>> thinking about the tradeoff  between the scheduler's complexity and
>> the benefit brought by introducing complexity.
>>
>> The work-conserving mode is useful. However, there are other real
>> time
>> features in terms of the scheduler that may be also useful. For
>> example, I heard from some company that they want to run RT VM with
>> non-RT VM, which is supported in RT-Xen 2.1 version, but not
>> supported
>> in RTDS.
>>
> I remember that, but I'm not sure what "running a non-RT VM" inside
> RTDS would mean. According to what algorithm these non real-time VMs
> would be scheduled?

A non-RT VM means the VM whose priority is lower than any RT VM. The
non-RT VMs won't get scheduled until all RT VMs have  been scheduled.
We can use the same gEDF scheduling policy to schedule non-RT VMs.

>
> Since you mentioned complexity, adding a work conserving mode should be
> easy enough, and if you allow a VM to be in work conserving mode, and
> have a very small (or even zero) budget, here you are a non real-time
> VM.

OK. I think it depends on what algorithm we want to use for the work
conserving mode? Do you have some algorithm in mind?

>
>> There are other RT-related issues we may need to solve to make it
>> more
>> suitable for real-time or embedded field, such as protocols to handle
>> the shared resource.
>>
>> Since the scheduler aims for the embedded and real-time applications,
>> those RT-related features seems to me more important than the
>> work-conserving feature.
>>
>> What do you think?
>>
> There always will be new/other features... But that's not the point.

OK.

>
> What we need, here, is agree on what is the _minimum_ set of them that
> allows us to call the scheduler complete and usable. I think we're
> pretty close, with this work conserving mode I'm talking about the only
> candidate I can think of.

Since the point you raised here is that the work-conserving is
(probably) a must.

>
>> >
>> > You may have something similar in RT-Xen already but, even
>> > if you don't, there are a number of ways for achieving that without
>> > disrupting the real-time guarantees.
>> Actually, in RT-Xen, we don't have the work-conserving version yet.
>>
> Yeah, sorry, I probably was confusing it with the "RT / non-RT" flag.

I see. :-)

Best regards,

Meng

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

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Dario Faggioli]

On Tue, 2016-04-26 at 16:00 -0400, Meng Xu wrote:
> > 
> > > 
> > > The feature document template has been put together:
> > > http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01
> > > 929.html
> > > 
> > > And there are feature documents in tree already.
> > > 
> > > Actually, writing one for RTDS would be a rather interesting and
> > > useful
> > > thing to do, IMO! :-)
> > I think it would be helpful to try to spell out what we think are
> > the
> > criteria for marking RTDS non-experimental.  Reading your e-mail,
> > Dario,
> > I might infer the following criteria:
> > 
> > 1. New event-driven code spends most of a full release cycle in the
> > tree
> > being tested
> > 2. Better tests in osstest (which ones?)
> > 3. A feature doc
> I agree with the above three items.
> 
Great!

> > 4. A work-conserving mode
> I think we need to consider the item 4 carefully. Work-conserving
> mode
> is not a must for real-time schedulers and it is not the main
> purpose/goal of the RTDS scheduler.
> 
It's indeed not a must for real-time schedulers. In fact, it's only
important if one wants the system to be overall usable, when using a
real-time scheduler. :-P

Also, I may be wrong but it should not be too hard to implement...
I.e., a win-win. :-)

> > Regarding #2, did you have specific tests in mind?
> I've been thinking about how to confirm the correctness of (RTDS)
> schedulers. It is actually quite challenging to prove the scheduler
> is
> correct.
> 
> I'm thinking what the goal of the tests is? It will determine how the
> scheduler should be tested, IMHO.
> There are three possible goals in increasing difficulty:
> (1) Make sure the scheduler won't crash the system, or
> (2) make sure the performance of the scheduler is correct, or
> (3) prove the scheduler is correct?
> 
> Which one are we talking about here? (maybe item 1?)
> 
Definitely 1, with all the security related implications that applies
to it (e.g., if a guest running within RTDS could crash or DoS the
entire host, that would be a security issue).

Good performance is important, but we'd need to define what 'good
performance' means. And since this is the only (online) real-time
scheduler we have, maybe that is not really necessary for now (e.g.,
'good performance', as compared to what?).

Assessing correctness of the actual schedule is interesting, but beyond
the scope of what I'd call 'supported status'. :-)

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



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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Dario Faggioli]

On Tue, 2016-04-26 at 14:38 -0400, Meng Xu wrote:
> > So, yes, the scheduler is now feature complete (with the per-vcpu
> > parameters) and adheres to a much more sensible and scalable design
> > (event driven). Yet, these features have been merged very recently,
> > therefore, when you say "tested", I'm not so sure I agree. In fact,
> > we
> > do test it on OSSTest, but only in a couple of tests. The
> > combination
> > of these two things make me think that we should allow for at least
> > another development cycle, before considering switching.
> I see. So should we mark it as Completed for Xen 4.7? or should we
> wait until Xen 4.8 to mark it as Completed if nothing bad happens to
> the scheduler?
> 
We should define the criteria. :-)

In any case, not earlier than 4.8, IMO.

> > And even in that case, I wonder how we should handle such a
> > situation... I was thinking of adding a work-conserving mode, what
> > do
> > you think?
> Hmm, I can get why work-conserving mode is necessary and useful. I'm
> thinking about the tradeoff  between the scheduler's complexity and
> the benefit brought by introducing complexity.
> 
> The work-conserving mode is useful. However, there are other real
> time
> features in terms of the scheduler that may be also useful. For
> example, I heard from some company that they want to run RT VM with
> non-RT VM, which is supported in RT-Xen 2.1 version, but not
> supported
> in RTDS.
> 
I remember that, but I'm not sure what "running a non-RT VM" inside
RTDS would mean. According to what algorithm these non real-time VMs
would be scheduled?

Since you mentioned complexity, adding a work conserving mode should be
easy enough, and if you allow a VM to be in work conserving mode, and
have a very small (or even zero) budget, here you are a non real-time
VM.

> There are other RT-related issues we may need to solve to make it
> more
> suitable for real-time or embedded field, such as protocols to handle
> the shared resource.
> 
> Since the scheduler aims for the embedded and real-time applications,
> those RT-related features seems to me more important than the
> work-conserving feature.
> 
> What do you think?
> 
There always will be new/other features... But that's not the point.

What we need, here, is agree on what is the _minimum_ set of them that
allows us to call the scheduler complete and usable. I think we're
pretty close, with this work conserving mode I'm talking about the only
candidate I can think of.

> > 
> > You may have something similar in RT-Xen already but, even
> > if you don't, there are a number of ways for achieving that without
> > disrupting the real-time guarantees.
> Actually, in RT-Xen, we don't have the work-conserving version yet.
>
Yeah, sorry, I probably was confusing it with the "RT / non-RT" flag.

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



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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Dario Faggioli]

On Tue, 2016-04-26 at 16:35 +0100, George Dunlap wrote:
> On 26/04/16 08:56, Dario Faggioli wrote:
> > 
> > On Mon, 2016-04-25 at 21:44 -0400, Meng Xu wrote:
> > > 
> > Actually, writing one for RTDS would be a rather interesting and
> > useful
> > thing to do, IMO! :-)
> I think it would be helpful to try to spell out what we think are the
> criteria for marking RTDS non-experimental.
>
Indeed.

>   Reading your e-mail, Dario,
> I might infer the following criteria:
> 
Thanks for this :-)

> 1. New event-driven code spends most of a full release cycle in the
> tree
> being tested
> 2. Better tests in osstest (which ones?)
> 3. A feature doc
> 4. A work-conserving mode
> 
> Is that about right?
> 
I think it is.

> #3 definitely sounds like a good idea.  #1 is probably reasonable.
> 
Good that we agree on this.

> I don't think #4 should be a blocker; we have plenty of work-
> conserving
> schedulers. :-)
> 
I am not absolutely sure about this either.

We do have work conserving schedulers, and one can partition the system
in cpupools and assign each VM to the one that best suits its needs.

Yet, think at someone wanting to boot Xen with "sched=rtds". This may
be someone wanting to play with/try the RTDS scheduler, it could be our
OSSTest jobs (the one that wants to test RTDS), or it could be someone
with a small enough system that partitioning it with cpupools is not
desirable.

What this 'someone' would get is a dom0 that only has
(4*nr_dom0_vcpus)% CPU capacity available. If (let's assume we are in
the small system case, which as a matter of fact is also the case of
some of our test jobs) dom0 has 2 vcpus, this means 8% CPU total
capacity. The rest 92% of the time, the CPUs will just stay idle.

Let's assume that our 'someone' tries doing a local migration (OSSTest
does that). Or connecting with SSH and/or copying some medium to large
files with rsync. What would happen (and in fact, this is what happens
to OSSTest, as far as I can tell) is that things will timeout all the
time, migrations, sessions and file transfers would be incredibly slow.

And therefore, our dear 'someone' would, IMO, just turn away and look
at something else. Or will email xen-devel reporting a bug about
migration being slow, or connections timing out on Xen.

Increasing the reservation for dom0 --maybe even by default-- would
certainly allow to mitigate this, but at the cose of having less
bandwidth available to be guaranteed for actual, guests which is
certainly non desirable.

Of course, the same exact scenario just described, applies even if the
system is fully booked by guest domains, but all or most of them are
idle. There will again be a lot of idle time, while a couple of domains
(in the example at hand, just dom0) struggle to get done all they're
asked to do in their 8%! :-O

A work-conserving mode, selectable together with the other scheduling
parameters (and maybe enabled by default for dom0, and with a dedicated
boot parameter to change/affect that) would, according to me, provide a
more than decent solution, in a very simple way. It's not the perfect
solution. Not even the best one, probably. There are more advanced
techniques (like adaptive reservations, and others) but they all come
at a high price in terms of development and maintainability effort.

So, yeah, I'm not entirely sure yet, but I think a work conserving mode
could be very useful and should be regarded as important...

> Regarding #2, did you have specific tests in mind?
> 
Nothing too advanced. This is a special purpose scheduler and need to
be tested by people that actually need it, and on their workload.

Still, there's a test case stressing cpupools code that also involves
this scheduler that I've been working on-&-off for a while now, that I
think would be really useful (and in fact, I want to finish it).

I also want to add a test (not sure how yet: a new job, a phase of a
job, etc), that plays with the scheduling parameters of all schedulers
(weights for Credit 1 and 2, budget and period for this).

There's not much else that I can think of, but this would be already
quite a bit better than now.

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



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

[Xen-devel] [xen-4.3-testing test] 92825: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  5 xen-install fail pass in 92778

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-libvirt  6 xen-boot  fail in 92778 never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass

version targeted for testing:
 xen  c04846eeb3d96cf670dc5894b66f3f6e61c2531d
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-

[Xen-devel] [PATCH 3.19.y-ckt 53/66] x86/mm/xen: Suppress hugetlbfs in PV guests

[Kamal Mostafa]

3.19.8-ckt20 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Jan Beulich 

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 68c0539..7aadd3c 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
-- 
2.7.4


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

[Xen-devel] [ovmf test] 92813: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 4a21fb3b67a0ef1655b43e9368b6b697bbf327af
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  140 days
Failing since 65593  2015-12-08 23:44:51 Z  139 days  180 attempts
Testing same since92813  2016-04-26 06:37:54 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Meng Xu]

>> The feature document template has been put together:
>> http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01929.html
>>
>> And there are feature documents in tree already.
>>
>> Actually, writing one for RTDS would be a rather interesting and useful
>> thing to do, IMO! :-)
>
> I think it would be helpful to try to spell out what we think are the
> criteria for marking RTDS non-experimental.  Reading your e-mail, Dario,
> I might infer the following criteria:
>
> 1. New event-driven code spends most of a full release cycle in the tree
> being tested
> 2. Better tests in osstest (which ones?)
> 3. A feature doc

I agree with the above three items.

> 4. A work-conserving mode

I think we need to consider the item 4 carefully. Work-conserving mode
is not a must for real-time schedulers and it is not the main
purpose/goal of the RTDS scheduler.

>
> #3 definitely sounds like a good idea.  #1 is probably reasonable.
>
> I don't think #4 should be a blocker; we have plenty of work-conserving
> schedulers. :-)

Exactly.. Actually, work-conserving feature is not a top property for
real-time applications. The resource sharing issues, interacted with
the scheduler, are more important than the work-conserving "issue" for
complex non-independent real-time applications.

>
> Regarding #2, did you have specific tests in mind?

I've been thinking about how to confirm the correctness of (RTDS)
schedulers. It is actually quite challenging to prove the scheduler is
correct.

I'm thinking what the goal of the tests is? It will determine how the
scheduler should be tested, IMHO.
There are three possible goals in increasing difficulty:
(1) Make sure the scheduler won't crash the system, or
(2) make sure the performance of the scheduler is correct, or
(3) prove the scheduler is correct?

Which one are we talking about here? (maybe item 1?)

Thanks,

Meng

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

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

[Xen-devel] [3.19.y-ckt stable] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" has been added to the 3.19.y-ckt tree

[Kamal Mostafa]

This is a note to let you know that I have just added a patch titled

x86/mm/xen: Suppress hugetlbfs in PV guests

to the linux-3.19.y-queue branch of the 3.19.y-ckt extended stable tree 
which can be found at:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y-queue

This patch is scheduled to be released in version 3.19.8-ckt20.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.19.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Kamal

---8<

From d34f71f0ba7a50c24907c38797f54bc303b4ca44 Mon Sep 17 00:00:00 2001
From: Jan Beulich 
Date: Thu, 21 Apr 2016 00:27:04 -0600
Subject: x86/mm/xen: Suppress hugetlbfs in PV guests

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 68c0539..7aadd3c 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 

+#define hugepages_supported() cpu_has_pse

 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
--
2.7.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  9772c480a71ad38cc2c342e4c2e78c2475de7268
baseline version:
 xen  488c2a860a6d7eb69f4acfeb349b457aaba76dfa

Last test of basis92731  2016-04-25 17:04:22 Z1 days
Failing since 92827  2016-04-26 10:06:00 Z0 days3 attempts
Testing same since92860  2016-04-26 17:23:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper
  Doug Goldstein 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Meng Xu]

On Tue, Apr 26, 2016 at 4:56 AM, Andrew Cooper
 wrote:
>
>>> However, inside MAINTAINERS file, the status of RTDS scheduler is
>>> marked as Supported (refer to commit point 28041371 by Dario Faggioli
>>> on 2015-06-25).
>>>
>> There's indeed a discrepancy between the way one can read that bit of
>> MAINTAINERS, and what is generally considered Supported (e.g., subject
>> to security support, etc).
>>
>> This is true in general, not only for RTDS (more about this below).
>
> The purpose of starting the feature docs (in docs/features/) was to
> identify the technical status of a feature, along side some
> documentation pertinent to its use.
>
> I am tempted to suggest a requirement of "no security support without a
> feature doc" for new features, in an effort to resolve the current
> uncertainty as to what is supported and what is not.

I see. As I said in Dario's reply, I will add a feature doc in the
summer about the RTDS scheduler.

>
> As for the MAINTAINERS file, supported has a different meaning.  From
> the file itself,

Right. I read this doc before asking. :-)

>
> Descriptions of section entries:
>
> M: Mail patches to: FullName 
> L: Mailing list that is relevant to this area
> W: Web-page with status/info
> T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
> S: Status, one of the following:
>Supported:   Someone is actually paid to look after this.
>Maintained:  Someone actually looks after it.
>Odd Fixes:   It has a maintainer but they don't have time to do
> much other than throw the odd patch in. See below..
>Orphan:  No current maintainer [but maybe you could take the
> role as you write your new code].
>Obsolete:Old code. Something tagged obsolete generally means
> it has been replaced by a better system and you
> should be using that.
>
> Nothing in the MAINTAINERS file constitutes a security statement.

I didn't realize this before.

Thank you very much for clarification!

Meng

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

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Meng Xu]

>> When RTDS scheduler is initialized, it will print out that the
>> scheduler is an experimental feature with the following lines:
>>
>> printk("Initializing RTDS scheduler\n"
>>
>>"WARNING: This is experimental software in development.\n"
>>
>>"Use at your own risk.\n");
>>
>> On RTDS' wiki [1], it says the RTDS scheduler is experimental
>> feature.
>>
> Yes.
>
>> However, inside MAINTAINERS file, the status of RTDS scheduler is
>> marked as Supported (refer to commit point 28041371 by Dario Faggioli
>> on 2015-06-25).
>>
> There's indeed a discrepancy between the way one can read that bit of
> MAINTAINERS, and what is generally considered Supported (e.g., subject
> to security support, etc).
>
> This is true in general, not only for RTDS (more about this below).

Ah-ha, I see.

>
>> In my opinion, the RTDS scheduler's functionality is finished and
>> tested. So should I send a patch to change the message printed out
>> when the scheduler is initialized?
>>
> So, yes, the scheduler is now feature complete (with the per-vcpu
> parameters) and adheres to a much more sensible and scalable design
> (event driven). Yet, these features have been merged very recently,
> therefore, when you say "tested", I'm not so sure I agree. In fact, we
> do test it on OSSTest, but only in a couple of tests. The combination
> of these two things make me think that we should allow for at least
> another development cycle, before considering switching.

I see. So should we mark it as Completed for Xen 4.7? or should we
wait until Xen 4.8 to mark it as Completed if nothing bad happens to
the scheduler?

>
> And speaking of OSSTest, there have benn occasional failures, on ARM,
> which I haven't yet found the time to properly analyze. It may be just
> something related to the fact that the specific board was very slow,
> but I'm not sure yet.

Hmm, I see. I plan to have a look at Xen on ARM this summer. When I
boot Xen on ARM, I probably could have a look at it as well.

>
> And even in that case, I wonder how we should handle such a
> situation... I was thinking of adding a work-conserving mode, what do
> you think?

Hmm, I can get why work-conserving mode is necessary and useful. I'm
thinking about the tradeoff  between the scheduler's complexity and
the benefit brought by introducing complexity.

The work-conserving mode is useful. However, there are other real time
features in terms of the scheduler that may be also useful. For
example, I heard from some company that they want to run RT VM with
non-RT VM, which is supported in RT-Xen 2.1 version, but not supported
in RTDS.

There are other RT-related issues we may need to solve to make it more
suitable for real-time or embedded field, such as protocols to handle
the shared resource.

Since the scheduler aims for the embedded and real-time applications,
those RT-related features seems to me more important than the
work-conserving feature.

What do you think?

> You may have something similar in RT-Xen already but, even
> if you don't, there are a number of ways for achieving that without
> disrupting the real-time guarantees.

Actually, in RT-Xen, we don't have the work-conserving version yet.
The work-conversing feature may not affect the real-time guarantees,
but it may not bring any improved real-time guarantees in theory. When
an embedded system designer wants to use the RTDS scheduler "with
work-conserving feature" (suppose we implement it), he cannot pack
more workload to the system by leveraging the work-conserving feature.
In practice, the system may run faster than he expects, but he won't
know how faster it will be unless we provide theoretical guarantee.

>
> What do you think?

IMHO, handling the other real-time features related to the scheduler
may be more important than the work-conserving feature, in order to
make the scheduler more adoptable in embedded world.

>
>> If I understand correctly, the status in MAINTAINERS file should have
>> the highest priority and information from other sources should keep
>> updated with what the MAINTAINERS file says?
>>
>> Please correct me if I'm wrong.
>>
> This has been discussed before. Have a look at this thread/messages.
>
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00972.html
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01775.html

I remembered this. Always keep an eye on ARINC653 as well. :-)

>
> And at this:
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html

Yes. I read this before I asked. :-)

>
> The feature document template has been put together:
> http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01929.html

This is great!

>
> And there are feature documents in tree already.
I see.

>
> Actually, writing one for RTDS would be a rather interesting and useful
> thing to do, IMO! :-)

Agree. I can do it in the summer.  Put it on my TODO list now.

Thanks,

Meng

---
Meng Xu
PhD Student in Computer and Infor

[Xen-devel] [PATCH 4.2.y-ckt 77/93] x86/mm/xen: Suppress hugetlbfs in PV guests

[Kamal Mostafa]

4.2.8-ckt9 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Jan Beulich 

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index f8a29d2..e6a8613 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
-- 
2.7.4


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

Re: [Xen-devel] xen/arm: Assertion 'timer->status >= TIMER_STATUS_inactive' failed at timer.c:279

[Julien Grall]

On 26/04/16 18:49, Dario Faggioli wrote:

On Tue, 2016-04-26 at 15:25 +0100, Julien Grall wrote:
Hi,


Hi Dario,

[...]


commit eca4d65fb67a71c0f6563aafbfdd68e566c53c32
Author: Dario Faggioli 
Date:   Tue Apr 26 17:42:36 2016 +0200

 xen: sched: fix killing an uninitialized timer in free_pdata.

 commit 64269d9365 "sched: implement .init_pdata in Credit,
 Credit2 and RTDS" helped fixing Credit2 runqueues, and
 the races we had in switching scheduler for pCPUs, but
 introduced another issue. In fact, if CPU bringup fails
 during __cpu_up() (and, more precisely, after CPU_UP_PREPARE,
 but before CPU_STARTING) the CPU_UP_CANCELED notifier
 would be executed, which calls the free_pdata hook.

 Such hook does two things: (1) undo the initialization
 done inside the init_pdata hook; (2) free the memory
 allocated by the alloc_pdata hook.

 However, in the failure path just described, it is possible
 that only alloc_pdata has really been called, which is
 potentially and issue (depending on what actually happens
 inside the implementation of free_pdata).

 In fact, for Credit1 (the only scheduler that actually
 allocates per-pCPU data), this result in calling kill_timer()
 on a timer that had not yet been initialized, which causes
 the following:

 (XEN) Xen call trace:
 (XEN)[<0022e304>] timer.c#active_timer+0x8/0x24 (PC)
 (XEN)[<0022f624>] kill_timer+0x108/0x2e0 (LR)
 (XEN)[<002208c0>] sched_credit.c#csched_free_pdata+0xd8/0x114
 (XEN)[<00227a18>] schedule.c#cpu_schedule_callback+0xc0/0x12c
 (XEN)[<00219944>] notifier_call_chain+0x78/0x9c
 (XEN)[<002015fc>] cpu_up+0x104/0x130
 (XEN)[<0028f7c0>] start_xen+0xaf8/0xce0
 (XEN)[<810021d8>] 810021d8
 (XEN)
 (XEN)
 (XEN) 
 (XEN) Panic on CPU 0:
 (XEN) Assertion 'timer->status >= TIMER_STATUS_inactive' failed at 
timer.c:279
 (XEN) 

 Solve this by making the scheduler hooks API symmetric again,
 i.e., by adding an deinit_pdata hook and making it responsible
 of undoing what init_pdata did, rather than asking to free_pdata
 to do everything.

 This is cleaner and, in the case at hand, makes it possible to
 only call free_pdata, which is the right thing to do, as only
 allocation and no initialization was performed.

 Reported-by: Julien Grall 
 Signed-off-by: Dario Faggioli 
 ---
 Cc: George Dunlap 
 Cc: Konrad Rzeszutek Wilk 
 Cc: varun.sw...@arm.com
 Cc: Steve Capper 


Thank you for the patch. It fixes the bug when secondary CPUs fail to 
come online on the Foundation Model:


Tested-by: Julien Grall 

Regards,

--
Julien Grall

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

[Xen-devel] [linux-mingo-tip-master test] 92800: regressions - FAIL

[osstest service owner]

flight 92800 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92800/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-libvirt-xsm  14 guest-saverestorefail   like 60684
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux590844d34bb1916d05d54841aab8aa0919c7f3b3
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  257 days
Failing since 60712  2015-08-15 18:33:48 Z  254 days  196 attempts
Testing same since92800  2016-04-26 04:34:16 Z0 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm 

Re: [Xen-devel] [PATCH v9 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Konrad Rzeszutek Wilk]

On Tue, Apr 26, 2016 at 04:21:10AM -0600, Jan Beulich wrote:
> >>> On 25.04.16 at 17:34,  wrote:
> > The implementation does not actually do any patching.
> > 
> > It just adds the framework for doing the hypercalls,
> > keeping track of ELF payloads, and the basic operations:
> >  - query which payloads exist,
> >  - query for specific payloads,
> >  - check*1, apply*1, replace*1, and unload payloads.
> > 
> > *1: Which of course in this patch are nops.
> > 
> > The functionality is disabled on ARM until all arch
> > components are implemented.
> > 
> > Also by default it is disabled until the implementation
> > is in place.
> > 
> > We also use recursive spinlocks to so that the find_payload
> > function does not need to have a 'lock' and 'non-lock' variant.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > Signed-off-by: Ross Lagerwall 
> > Reviewed-by: Andrew Cooper 
> > Acked-by: Daniel De Graaf 
> 
> I'm hesitant to say that, but with all of this:
> 
> > v9:
> > s/find_name/get_name/, drop locks when allocating data.
> > Drop conditional expression on copyback
> > Move the allocation on upload outside the spinlock.
> > Add (TECH PREVIEW) to the Kconfig help
> > Return -EINVAL if the CHECK or UNLOAD action is to be performed and the 
> > payload
> > state is not in expected state.
> > Print 'c' not 'u' when invoking the keyhandler.
> 
> ... I'm not sure the earlier R-b can still be considered valid. Andrew?

I don't know what the criteria is for dropping an Reviewed-by.
I am happy to drop it if you would like - but it may be that Andrew
is OK with the way he had his review?

Or is this more of your view as maintainer - that is the patch
changed considerably (and what is that? percentage of the patch?
small amount of the patch? Trivial changes? Dropping code?)?
> 
> > +static int get_name(const xen_xsplice_name_t *name, char *n)
> > +{
> > +if ( !name->size || name->size > XEN_XSPLICE_NAME_SIZE )
> > +return -EINVAL;
> > +
> > +if ( name->pad[0] || name->pad[1] || name->pad[2] )
> > +return -EINVAL;
> > +
> > +if ( !guest_handle_okay(name->name, name->size) )
> > +return -EINVAL;
> > +
> > +if ( __copy_from_guest(n, name->name, name->size) )
> > +return -EFAULT;
> 
> Quoting part of my v8.1 reply:
> "Is there a particular reason why you open code copy_from_guest() here?"

You mean why I use guest_handle_okay and __copy_from_guest instead of
say copy_from_guest?

I think it is an artificat of earlier changes - in which the find_name
would only check 'name-size' and then in another function we would
just do '__copy_from_guest'. But that is not needed anymore - so let
me change it to 'copy_from_guest'
I thought at some point you asked for that as the check was done for
it once and there was no point
> 
> > +static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
> > +{
> > +struct payload *data, *found;
> > +char n[XEN_XSPLICE_NAME_SIZE];
> > +int rc;
> > +
> > +rc = verify_payload(upload, n);
> > +if ( rc )
> > +return rc;
> > +
> > +data = xzalloc(struct payload);
> > +
> > +spin_lock(&payload_lock);
> > +
> > +found = find_payload(n);
> > +if ( IS_ERR(found) )
> > +{
> > +rc = PTR_ERR(found);
> > +goto out;
> > +}
> > +else if ( found )
> > +{
> > +rc = -EEXIST;
> > +goto out;
> > +}
> > +
> > +if ( !data )
> > +{
> > +rc = -ENOMEM;
> > +goto out;
> > +}
> > +
> > +rc = 0;
> 
> rc is already zero by the time we get here.
> 
> I also wonder whether the code wouldn't be easier to read if you
> used just a sequence of if()/else if() here, without any goto-s.

But I do need to free(data) and unlock the spinlock - so having
a common code to pass through makes sense.

Unless you mean have an condition on if ( !rc ), and do the normal path?
Like so:

rc = verify_payload(upload, n);
if ( rc )
return rc;

data = xzalloc(struct payload);

spin_lock(&payload_lock);

found = find_payload(n);
if ( IS_ERR(found) )
rc = PTR_ERR(found);
else if ( found )
rc = -EEXIST;

if ( !rc && !data )
rc = -ENOMEM;

if ( !rc )
{
memcpy(data->name, n, strlen(n));
data->state = XSPLICE_STATE_CHECKED;
INIT_LIST_HEAD(&data->list);

list_add_tail(&data->list, &payload_list);
payload_cnt++;
payload_version++;
}

spin_unlock(&payload_lock);

if ( rc )
xfree(data);

return rc;


That looks fine here, but in the subsequent patch I have to also
check for

if ( __copy_from_guest(raw_data, upload->payload, upload->size) )   

and
rc = load_payload_data(data, raw_data, upload->size);

and goto statement help a lot there.

I would rather have it the way it is now if you are OK with that?




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

Re: [Xen-devel] xen/arm: Assertion 'timer->status >= TIMER_STATUS_inactive' failed at timer.c:279

[Dario Faggioli]

On Tue, 2016-04-26 at 15:25 +0100, Julien Grall wrote:
> Hi Dario,
> 
Hi,

> A couple of people have been reported Xen crash on the ARM64
> Foundation Model [1] with recent unstable.
> 
Ok, thanks for reporting.

> The crash seems to happen when Xen fails to bring up secondary CPUs
> (see stack trace below).
> 
Ah... I see.

> From my understanding, csched_free_pdata is trying to kill the
> timer spc->ticker. However the status of this timer is
> TIMER_STATUS_invalid.
> 
> This is because csched_init_pdata has set a deadline for the
> timer (set_timer) and the softirq to schedule the timer has
> not yet happen (indeed Xen is still in early boot).
> 
Yes, this is sort of what happens (only slightly different, see the
changelog of the atached patch patch).


> I am not sure how to fix this issue. How will you recommend
> to fix it?
> 
Yeah, well, doing it cleanly includes a slight change in the scheduler
hooks API, IMO... and we indeed should do it cleanly :-))

George, what do you think?

Honestly, this is similar to what I was thinking to do already (I mean,
having an deinit_pdata hook, "symmetric" with the init_pdata one), when
working on that series, because I do think it's cleaner... then, I
abandoned the idea, as it looked to not be necessary... But apparently
it may actually be! :-)

Let me know, and I'll resubmit the patch properly (together with
another bugfix I have in my queue).

Dario
---
commit eca4d65fb67a71c0f6563aafbfdd68e566c53c32
Author: Dario Faggioli 
Date:   Tue Apr 26 17:42:36 2016 +0200

xen: sched: fix killing an uninitialized timer in free_pdata.

commit 64269d9365 "sched: implement .init_pdata in Credit,
Credit2 and RTDS" helped fixing Credit2 runqueues, and
the races we had in switching scheduler for pCPUs, but
introduced another issue. In fact, if CPU bringup fails
during __cpu_up() (and, more precisely, after CPU_UP_PREPARE,
but before CPU_STARTING) the CPU_UP_CANCELED notifier
would be executed, which calls the free_pdata hook.

Such hook does two things: (1) undo the initialization
done inside the init_pdata hook; (2) free the memory
allocated by the alloc_pdata hook.

However, in the failure path just described, it is possible
that only alloc_pdata has really been called, which is
potentially and issue (depending on what actually happens
inside the implementation of free_pdata).

In fact, for Credit1 (the only scheduler that actually
allocates per-pCPU data), this result in calling kill_timer()
on a timer that had not yet been initialized, which causes
the following:

(XEN) Xen call trace:
(XEN)[<0022e304>] timer.c#active_timer+0x8/0x24 (PC)
(XEN)[<0022f624>] kill_timer+0x108/0x2e0 (LR)
(XEN)[<002208c0>] sched_credit.c#csched_free_pdata+0xd8/0x114
(XEN)[<00227a18>] schedule.c#cpu_schedule_callback+0xc0/0x12c
(XEN)[<00219944>] notifier_call_chain+0x78/0x9c
(XEN)[<002015fc>] cpu_up+0x104/0x130
(XEN)[<0028f7c0>] start_xen+0xaf8/0xce0
(XEN)[<810021d8>] 810021d8
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion 'timer->status >= TIMER_STATUS_inactive' failed at 
timer.c:279
(XEN) 

Solve this by making the scheduler hooks API symmetric again,
i.e., by adding an deinit_pdata hook and making it responsible
of undoing what init_pdata did, rather than asking to free_pdata
to do everything.

This is cleaner and, in the case at hand, makes it possible to
only call free_pdata, which is the right thing to do, as only
allocation and no initialization was performed.

Reported-by: Julien Grall 
Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Konrad Rzeszutek Wilk 
Cc: varun.sw...@arm.com
Cc: Steve Capper 

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index bc36837..0a6a1b4 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -482,15 +482,25 @@ static inline void __runq_tickle(struct csched_vcpu *new)
 }
 
 static void
-csched_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
+csched_free_pdata(const struct scheduler *ops, void *pcpu)
 {
-struct csched_private *prv = CSCHED_PRIV(ops);
 struct csched_pcpu *spc = pcpu;
-unsigned long flags;
 
 if ( spc == NULL )
 return;
 
+xfree(spc);
+}
+
+static void
+csched_deinit_pdata(const struct scheduler *ops, void *pcpu, int cpu)
+{
+struct csched_private *prv = CSCHED_PRIV(ops);
+struct csched_pcpu *spc = pcpu;
+unsigned long flags;
+
+ASSERT(spc != NULL);
+
 spin_lock_irqsave(&prv->lock, flags);
 
 prv->credit -= prv->credits_per_tslice;
@@ -507,8 +517,6 @@ csched_free_pdata(const struct scheduler *ops, void *pcpu, 
int cpu)

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Andrew Cooper]

On 26/04/16 18:23, Razvan Cojocaru wrote:
> On 04/26/16 19:03, George Dunlap wrote:
>> On 19/04/16 17:35, Jan Beulich wrote:
>> Razvan Cojocaru  04/19/16 1:01 PM >>>
 I think this might be because the LOCK prefix should guarantee that the
 instruction that follows it has exclusive use of shared memory (for both
 reads and writes) but I might be misreading the docs:
>>> LOCK definitely has no effect on other than the instruction it gets applied
>>> to.
>> Sorry I wasn't involved in this discussion -- what was the conclusion here?
>>
>> FWIW Andy's suggestion of using a stub seemed like the most robust
>> solution, if that could be made to work.
>>
>> If you're going to submit a patch substantially similar to this one, let
>> me know so I can review the mm bits of the original patch.
> I'm not really sure.
>
> Regarding this version of the patch, Jan has asked for more information
> on the performance impact, but I'm not sure how to obtain it in a
> rigorous manner. If it is decided that a version of this patch is
> desirable, I can go on fixing the issues we've found and address the
> comments we've had so far and submit a new version.

XenServer did performance testing.  No observable impact for normal VM
workloads (which is to be expected, as an OS wouldn't normally LOCK the
instructions it uses for MMIO).  The per-cpu rwlocks have ~0 overhead
when the lock isn't held for writing.

>
> I'm not familiar with what the stub solution would imply, so I'm afraid
> I can't comment on that. This is not code I've had that much contact
> with prior to stumbling into this problem.

As for the fix I suggested, its probably prohibitive to fix the current
emulator, given the plans for a rewrite.  (And on that note, I really
need to write a design doc and post to the list).

~Andrew

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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Razvan Cojocaru]

On 04/26/16 19:03, George Dunlap wrote:
> On 19/04/16 17:35, Jan Beulich wrote:
> Razvan Cojocaru  04/19/16 1:01 PM >>>
>>> I think this might be because the LOCK prefix should guarantee that the
>>> instruction that follows it has exclusive use of shared memory (for both
>>> reads and writes) but I might be misreading the docs:
>>
>> LOCK definitely has no effect on other than the instruction it gets applied
>> to.
> 
> Sorry I wasn't involved in this discussion -- what was the conclusion here?
> 
> FWIW Andy's suggestion of using a stub seemed like the most robust
> solution, if that could be made to work.
> 
> If you're going to submit a patch substantially similar to this one, let
> me know so I can review the mm bits of the original patch.

I'm not really sure.

Regarding this version of the patch, Jan has asked for more information
on the performance impact, but I'm not sure how to obtain it in a
rigorous manner. If it is decided that a version of this patch is
desirable, I can go on fixing the issues we've found and address the
comments we've had so far and submit a new version.

I'm not familiar with what the stub solution would imply, so I'm afraid
I can't comment on that. This is not code I've had that much contact
with prior to stumbling into this problem.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 for-4.7 00/14] Fixes for compiling with clang

[Doug Goldstein]

On 4/26/16 11:12 AM, Wei Liu wrote:
> On Tue, Apr 26, 2016 at 04:52:09PM +0200, Roger Pau Monne wrote:
>> Hello,
>>
>> This is a set of bug fixes for compiling both the hypervisor and the 
>> toolstack with clang. I've only tested it with clang 3.8.0 from base 
>> FreeBSD, so I'm not sure if it's going to work with _all_ clang versions, 
>> but should be better than nothing.
>>
>> AFAICT, most of the issues that clang found on the toolstack are actual 
>> bugs, so it's worth trying to fix them before the release.
>>
>> Patches 1-4 are for the hypervisor, while patches 5-14 are for the 
>> toolstack.
>>
>> Thanks, Roger.
>>
> 
> I went through the series. Most patches are trivial, so I'm inclined to
> take this series in 4.7.
> 
> There are a few patches that require updating. You can either resend the
> whole series with all tags folded in or just update those patches that
> require updating. Do whatever most convenient for you.
> 
> Wei.
> 

FWIW, a lot of these are individual patches and don't build on each
other. If some end up being controversial we can push the ones that have
a broad consensus.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] MiniOS on ARM64

[Julien Grall]

Hi Chen,

IIRC, you mentioned during the last Linaro Connect that you are working 
on an ARM64 port of MiniOS.


Anastassios, in CC, is interested get MiniOS running on ARM64 as well.

Do you know what is missing to get MiniOS booting? I have found a tree 
on your github for the port [1], is it the latest version?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Clarify the meaning of nested maintainership

[Lars Kurth]

On 26/04/2016 17:19, "George Dunlap"  wrote:

>On 21/04/16 17:59, Lars Kurth wrote:
>> 
>> 
>> On 21/04/2016 17:03, "George Dunlap"  wrote:
>> 
>>> Clarify the meaning of nested maintainership.
>>>
>>> Signed-off-by: George Dunlap 
>>> ---
>>>
>>> MAINTAINERS | 34 ++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index a34685d..be901d5 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -94,6 +94,40 @@ Descriptions of section entries:
>>>   printk, pr_info or pr_err
>>>One regex pattern per line.  Multiple K: lines acceptable.
>>>
>>> +
>>> +The meaning of nesting:
>>> +
>>>
>>> [snip]
>> 
>>> + - In the case of a disagreement between maintainers, THE REST can
>>> + vote to settle the matter.  (This should be very exceptional indeed.)
>> 
>> This creates a slight conflict with the project governance, which states
>> that committers act as referees in case of disagreements. As REST
>> maintainers are a superset of committers, this could create a potential
>> mismatch.
>> 
>> Given, that the text says "can", I don't have an issue with it. It
>>merely
>> adds an extra level of complexity when it comes to resolving
>>disagreements
>> and maybe could be confusing.
>
>With Keir gone, is that actually the case anymore?  I think at the
>moment REST == committers.
>
>And the logic behind putting the committers under the REST seemed to me
>in part to make the logic match up.

That is fine with me. I just picked up on it, because further up the patch
you said

+Many maintanership areas are "nested": for example, there are entries
+for xen/arch/x86 as well as xen/arch/x86/mm, and even
+xen/arch/x86/mm/shadow; and there is a section at the end called "THE
+REST" which lists all committers, as well as a few more.
   ^

Lars

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  4561569a11353688b97220be8d6a0821d53b97a6
baseline version:
 xen  488c2a860a6d7eb69f4acfeb349b457aaba76dfa

Last test of basis92731  2016-04-25 17:04:22 Z0 days
Failing since 92827  2016-04-26 10:06:00 Z0 days2 attempts
Testing same since92847  2016-04-26 14:02:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 4561569a11353688b97220be8d6a0821d53b97a6
Author: Jan Beulich 
Date:   Tue Apr 26 13:47:21 2016 +0200

x86/HVM: slightly improve hvm_mmio_{first,last}_byte()

EFLAGS.DF can be assumed to be usually clear, so unlikely()-annotate
the conditionals accordingly.

Also prefer latching p->size (used twice) into a local variable, at
once making it unnecessary for the reader to be sure expressions get
evaluated left to right (operand promotion would yield a different
result if p->addr + p->size - 1 was evaluted right to left).

Signed-off-by: Jan Beulich 
Reviewed-by: Paul Durrant 
Release-acked-by: Wei Liu 

commit 276da2785e3797885aadb135a957279b73ecf076
Author: Jan Beulich 
Date:   Tue Apr 26 13:47:02 2016 +0200

x86/HVM: correct last address emulation acceptance check

For REPeated memory access instructions the repeat count also needs to
be considered. Utilize that "last" already takes this into account.

Also defer computing "last" until we really know we need it.

Signed-off-by: Jan Beulich 
Reviewed-by: Paul Durrant 
Release-acked-by: Wei Liu 

commit 36e2f084ecb631838f04d73c6f7dc6bb305d0fe4
Author: Andrew Cooper 
Date:   Tue Apr 26 13:46:26 2016 +0200

x86/mm: introduce modify_xen_mappings()

To simply change the permissions on existing Xen mappings.  The existing
destroy_xen_mappings() is altered to support changing the PTE permissions.

A new destroy_xen_mappings() is introduced, as the special case of not 
passing
_PAGE_PRESENT to modify_xen_mappings().

As cleanup (and an ideal functional test), the boot logic which remaps Xen's
code and data with reduced permissions is altered to use
modify_xen_mappings(), rather than map_pages_to_xen() passing the same mfn's
back in.

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

commit 722b6d259f408b80c40e3ddb6b5909414be31f57
Author: Konrad Rzeszutek Wilk 
Date:   Tue Apr 26 11:54:08 2016 +0200

Revert "HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."

This reverts commit 2716d875379d538c1dfccad78a99ca7db2e09f90.

As it was decided that the existing XENVER hypercall - while having
grown organically over the years can still be expanded.

Signed-off-by: Konrad Rzeszutek Wilk 
Requested-and-acked-by: Jan Beulich 

commit f3598690741671a933eb372877bcb59f7036b1df
Author: Konrad Rzeszutek Wilk 
Date:   Tue Apr 26 11:53:49 2016 +0200

Revert "libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall"

This reverts commit d275ec9ca8a86f7c9c213f3551194d471ce90fbd.

As we prefer to s

Re: [Xen-devel] [PATCH] MAINTAINERS: Clarify the meaning of nested maintainership

[George Dunlap]

On 21/04/16 17:59, Lars Kurth wrote:
> 
> 
> On 21/04/2016 17:03, "George Dunlap"  wrote:
> 
>> Clarify the meaning of nested maintainership.
>>
>> Signed-off-by: George Dunlap 
>> ---
>>
>> MAINTAINERS | 34 ++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a34685d..be901d5 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -94,6 +94,40 @@ Descriptions of section entries:
>>printk, pr_info or pr_err
>> One regex pattern per line.  Multiple K: lines acceptable.
>>
>> +
>> +The meaning of nesting:
>> +
>>
>> [snip]
> 
>> + - In the case of a disagreement between maintainers, THE REST can
>> + vote to settle the matter.  (This should be very exceptional indeed.)
> 
> This creates a slight conflict with the project governance, which states
> that committers act as referees in case of disagreements. As REST
> maintainers are a superset of committers, this could create a potential
> mismatch.
> 
> Given, that the text says "can", I don't have an issue with it. It merely
> adds an extra level of complexity when it comes to resolving disagreements
> and maybe could be confusing.

With Keir gone, is that actually the case anymore?  I think at the
moment REST == committers.

And the logic behind putting the committers under the REST seemed to me
in part to make the logic match up.

 -George

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

Re: [Xen-devel] [PATCH v2 for-4.7 00/14] Fixes for compiling with clang

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:09PM +0200, Roger Pau Monne wrote:
> Hello,
> 
> This is a set of bug fixes for compiling both the hypervisor and the 
> toolstack with clang. I've only tested it with clang 3.8.0 from base 
> FreeBSD, so I'm not sure if it's going to work with _all_ clang versions, 
> but should be better than nothing.
> 
> AFAICT, most of the issues that clang found on the toolstack are actual 
> bugs, so it's worth trying to fix them before the release.
> 
> Patches 1-4 are for the hypervisor, while patches 5-14 are for the 
> toolstack.
> 
> Thanks, Roger.
> 

I went through the series. Most patches are trivial, so I'm inclined to
take this series in 4.7.

There are a few patches that require updating. You can either resend the
whole series with all tags folded in or just update those patches that
require updating. Do whatever most convenient for you.

Wei.

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

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

Re: [Xen-devel] [PATCH v9 18/27] xsplice: Add support for exception tables.

[Jan Beulich]

>>> On 25.04.16 at 17:35,  wrote:
> From: Ross Lagerwall 
> 
> Add support for exception tables contained within xSplice payloads. If an
> exception occurs search either the main exception table or a particular
> active payload's exception table depending on the instruction pointer.
> 
> Also we add an test-case to make sure we have an exception that
> is handled.
> 
> To not grow the code-base if xSplice is not compiled in we add
> certain #define to help in determining if code needs to be __init
> or not.
> 
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[George Dunlap]

On 19/04/16 17:35, Jan Beulich wrote:
 Razvan Cojocaru  04/19/16 1:01 PM >>>
>> I think this might be because the LOCK prefix should guarantee that the
>> instruction that follows it has exclusive use of shared memory (for both
>> reads and writes) but I might be misreading the docs:
> 
> LOCK definitely has no effect on other than the instruction it gets applied
> to.

Sorry I wasn't involved in this discussion -- what was the conclusion here?

FWIW Andy's suggestion of using a stub seemed like the most robust
solution, if that could be made to work.

If you're going to submit a patch substantially similar to this one, let
me know so I can review the mm bits of the original patch.

 -George


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

Re: [Xen-devel] [PATCH v2 for-4.7 10/14] libxl: add the printf-like attributes to a couple of functions

[Wei Liu]

On Tue, Apr 26, 2016 at 04:30:36PM +0100, Andrew Cooper wrote:
> On 26/04/16 16:29, Wei Liu wrote:
> > On Tue, Apr 26, 2016 at 04:52:19PM +0200, Roger Pau Monne wrote:
> > [...]
> >> @@ -1995,9 +1995,10 @@ _hidden libxl__json_object 
> >> *libxl__json_parse(libxl__gc *gc_opt, const char *s);
> >>  _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t 
> >> domid);
> >>/* Return the system-wide default device model */
> >>  _hidden libxl_device_model_version libxl__default_device_model(libxl__gc 
> >> *gc);
> >> -_hidden char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t 
> >> dm_domid,
> >> -  uint32_t domid,
> >> -  const char *format, ...) 
> >> PRINTF_ATTRIBUTE(4, 5);
> > Why does this not work with clang?
> 
> It is a security consideration.
> 
> Passing anything other than a string literal to a printf-style function
> is opening a can of worms if an untrusted entity can influence the
> content of the string.
> 

I see. I didn't look closely into the function body.

> I guess clang is better at spotting parameters passed like this than GCC.
> 

Sigh. I can't say I like turning that into a macro though. On the other
hand there doesn't seem to be an elegant way of solving that.

Roger, please at least make it look like a macro. Say, name it
DEVICE_MODEL_XS_PATH or something.

Wei.

> ~Andrew

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

Re: [Xen-devel] [PATCH v9 17/27] xsplice: Add support for bug frames.

[Jan Beulich]

>>> On 25.04.16 at 17:35,  wrote:
> From: Ross Lagerwall 
> 
> Add support for handling bug frames contained with xsplice modules. If a
> trap occurs search either the kernel bug table or an applied payload's
> bug table depending on the instruction pointer.
> 
> Signed-off-by: Ross Lagerwall 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v9 15/27] xsplice, symbols: Implement fast symbol names -> virtual addresses lookup

[Jan Beulich]

>>> On 25.04.16 at 17:35,  wrote:
> The current mechanism is geared towards fast virtual address ->
> symbol names lookup. This is fine for the normal use cases
> (BUG_ON, WARN_ON, etc), but for xSplice - where we need to find
> hypervisor symbols - it is slow.
> 
> To understand this patch, a description of the existing
> method is explained first. For folks familar go to 'NEW CODE:'.
> 
> HOW IT WORKS:
> 
> The symbol table lookup mechanism uses a simple encoding mechanism
> where it extracts the common ascii characters that the symbol's use.
> 
> This saves us space. The lookup mechanism is geared towards looking
> up symbols based on address. We have one 0..N (where N is
> the number of symbols, so 6849 for example) table:
> 
> symbols_addresses[0..N]
> 
> And an 1-1 (in a loose fashion) of the symbols (encoded) in a
> symbols_names stream of size N.
> 
> The N is variable (later on that below)
> 
> The symbols_names are sorted based on symbols_addresses, which
> means that the decoded entries inside symbols_names are not in
> ascending or descending order.
> 
> There is also the encoding mechanism - the table of 255 entries
> called symbols_token_index[]. And the symbols_token_table which
> is an stream of ASCIIZ characters, such as (it really
> is not a table as the values are variable):
> 
> @0   .asciz  "credit"
> @6   .asciz  "mask"
> ..
> @300 .asciz  "S"
> 
> And the symbols_token_index:
> @0.short  0
> @1.short  7
> @2.short  12
> @4.short  16
> ...
> @84 .short  300
> 
> The relationship between them is that the symbols_token_index
> gives us the offset to symbols_token_table.
> 
> The symbol_names[] array is a stream of encoded values. Each value
> follows the same pattern -  followed by .
> And the another  followed by .
> 
> Hence to find the right one you need to read , add 
> (to skip over), read , add , and so on until one
> finds the right tuple offset.
> 
> The  are the indicies into the symbols_token_index.
> 
> Meaning if you have:
>   0x04, 0x54, 0xda, 0xe2, 0x74
>   [4, 84, 218, 226, 116 in human numbering]
> 
> The 0x04 tells us that the symbol is four bytes past this one (so next
> symbol offset starts at 5). If we lookup symbols_token_index[84] we get 300.
> symbols_token[300] gets us the "S". And so on, the string eventually
> end up being decode to be 'S_stext'. The first character is the type,
> then optionally follwed by the filename (and # right after filename)
> and then lastly the symbol, such as:
> 
> tvpmu_intel.c#core2_vpmu_do_interrupt
> 
> Keep in mind that there are two fixed sized tables:
> symbols_addresses[0..symbols_num_syms], and
> symbols_markers[0..symbols_num_syms/255].
> 
> The symbols_markers is used to speed searching for the right address.
> It gives us the offsets within symbol_names that start at the value>.
> 
> The way to find a symbol based on the address is:
> 1) Figure out the 'tuple offset' from symbols_address[0..symbols_num_syms].
>This table is sorted by virtual addresses so finding the value is simple.
> 2) Get starting offset of symbol_names by retrieving value of
>symbol_markers['tuple offset' / 255].
> 3). Iterate up to 'tuple_offset & 255' in symbols_markers stream starting
>at 'offset'.
> 4). Decode the 
> 
> This however does not work very well if we want to search the other
> way - we have the symbol name and want to find the address.
> 
> NEW CODE:
> 
> To make that work we add one fixed size table called symbols_sorted_offsets 
> which
> has two elements: offset in symbol stream, offset in the symbol-address.
> 
> This whole array is sorted on the original symbol name during build-time
> (in case of collision we also take into account the type).
> 
> The values are for example:
> 
> symbols_sorted_offsets:
> .long 83363, 6302 # [.bss, len=5]
> .long 80459, 6084 # [.data, len=5]
> ..
> [The # added for clarity]
> 
> Which makes it incredibly easy to get in the symbols_names and also
> symbols_addresses (or symbols_offsets)
> 
> Searching for symbols is simplified as we can do a binary search
> on symbols_sorted_offsets. Since the symbols are sorted it takes on
> average 13 calls to symbols_expand_symbol.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v2 for-4.7 12/14] libxl: fix passing the type argument to xc_psr_*

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:21PM +0200, Roger Pau Monne wrote:
> The xc_psr_* functions expect the type to be xc_psr_cat_type instead of
> libxl_psr_cbm_type, so do the conversion.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_psr.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
> index 3d0dc61..40f2d5f 100644
> --- a/tools/libxl/libxl_psr.c
> +++ b/tools/libxl/libxl_psr.c
> @@ -298,6 +298,7 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
>uint64_t cbm)
>  {
>  GC_INIT(ctx);
> +BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
>  int rc;
>  int socketid, nr_sockets;
>  
> @@ -310,7 +311,8 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
>  libxl_for_each_set_bit(socketid, *target_map) {
>  if (socketid >= nr_sockets)
>  break;
> -if (xc_psr_cat_set_domain_data(ctx->xch, domid, type, socketid, 
> cbm)) {
> +if (xc_psr_cat_set_domain_data(ctx->xch, domid, 
> (xc_psr_cat_type)type,
> +   socketid, cbm)) {
>  libxl__psr_cat_log_err_msg(gc, errno);
>  rc = ERROR_FAIL;
>  }
> @@ -328,7 +330,8 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
>  GC_INIT(ctx);
>  int rc = 0;
>  
> -if (xc_psr_cat_get_domain_data(ctx->xch, domid, type, target, cbm_r)) {
> +if (xc_psr_cat_get_domain_data(ctx->xch, domid, (xc_psr_cat_type)type,
> +   target, cbm_r)) {
>  libxl__psr_cat_log_err_msg(gc, errno);
>  rc = ERROR_FAIL;
>  }
> -- 
> 2.6.4 (Apple Git-63)
> 

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

Re: [Xen-devel] [PATCH v9 14/27] xsplice, symbols: Implement symbol name resolution on address.

[Jan Beulich]

>>> On 25.04.16 at 17:35,  wrote:
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -798,12 +798,13 @@ ret_t 
> do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
>  static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
>  XEN_GUEST_HANDLE(char) nameh;
>  uint32_t namelen, copylen;
> +uint64_t addr;
>  
>  guest_from_compat_handle(nameh, op->u.symdata.name);
>  
>  ret = xensyms_read(&op->u.symdata.symnum, &op->u.symdata.type,
> -   &op->u.symdata.address, name);
> -
> +   &addr, name);
> +op->u.symdata.address = addr;

Wasn't the whole point of this change to have the argument be
a pointer to unsigned long? Why is the type of the new local
variable then uint64_t?

With that adjusted:
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v2 for-4.7 13/14] oxenstored: fix error when shifting negative value

[Andrew Cooper]

On 26/04/16 16:43, Wei Liu wrote:
> On Tue, Apr 26, 2016 at 04:37:49PM +0100, Andrew Cooper wrote:
>> On 26/04/16 16:35, Wei Liu wrote:
>>> The title is a bit too cryptic to me. Where do that shift happen?
>> Ocaml stores integers shifted left by one, and with the bottom bit set.
>>
>> Values with the bottom bit clear are pointers into the GC'd heap. 
>> Values with the bottom bit set are integers, and need to be shifted by 1
>> bit to have calculations performed.
>>
> This is better.
>
> Roger, can you add the above paragraphs to commit message? Thanks.

P.S. this is why Ocaml integers are 31 or 63 bits wide, and cause all
kinds of "fun" issues when interfacing with C which makes use of all
bits available in an integer.

~Andrew

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

Re: [Xen-devel] [PATCH v2 for-4.7 13/14] oxenstored: fix error when shifting negative value

[Wei Liu]

On Tue, Apr 26, 2016 at 04:37:49PM +0100, Andrew Cooper wrote:
> On 26/04/16 16:35, Wei Liu wrote:
> > The title is a bit too cryptic to me. Where do that shift happen?
> 
> Ocaml stores integers shifted left by one, and with the bottom bit set.
> 
> Values with the bottom bit clear are pointers into the GC'd heap. 
> Values with the bottom bit set are integers, and need to be shifted by 1
> bit to have calculations performed.
> 

This is better.

Roger, can you add the above paragraphs to commit message? Thanks.

Wei.

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

Re: [Xen-devel] [PATCH v2 for-4.7 13/14] oxenstored: fix error when shifting negative value

[Andrew Cooper]

On 26/04/16 16:35, Wei Liu wrote:
> The title is a bit too cryptic to me. Where do that shift happen?

Ocaml stores integers shifted left by one, and with the bottom bit set.

Values with the bottom bit clear are pointers into the GC'd heap. 
Values with the bottom bit set are integers, and need to be shifted by 1
bit to have calculations performed.

Underlying patch Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[George Dunlap]

On 26/04/16 08:56, Dario Faggioli wrote:
> On Mon, 2016-04-25 at 21:44 -0400, Meng Xu wrote:
>> Hi Dario and all,
>>
> Hi,
> 
>> When RTDS scheduler is initialized, it will print out that the
>> scheduler is an experimental feature with the following lines:
>>
>> printk("Initializing RTDS scheduler\n"
>>
>>"WARNING: This is experimental software in development.\n"
>>
>>"Use at your own risk.\n");
>>
>> On RTDS' wiki [1], it says the RTDS scheduler is experimental
>> feature.
>>
> Yes.
> 
>> However, inside MAINTAINERS file, the status of RTDS scheduler is
>> marked as Supported (refer to commit point 28041371 by Dario Faggioli
>> on 2015-06-25).
>>
> There's indeed a discrepancy between the way one can read that bit of
> MAINTAINERS, and what is generally considered Supported (e.g., subject
> to security support, etc).
> 
> This is true in general, not only for RTDS (more about this below).
> 
>> In my opinion, the RTDS scheduler's functionality is finished and
>> tested. So should I send a patch to change the message printed out
>> when the scheduler is initialized?
>>
> So, yes, the scheduler is now feature complete (with the per-vcpu
> parameters) and adheres to a much more sensible and scalable design
> (event driven). Yet, these features have been merged very recently,
> therefore, when you say "tested", I'm not so sure I agree. In fact, we
> do test it on OSSTest, but only in a couple of tests. The combination
> of these two things make me think that we should allow for at least
> another development cycle, before considering switching.
> 
> And speaking of OSSTest, there have benn occasional failures, on ARM,
> which I haven't yet found the time to properly analyze. It may be just
> something related to the fact that the specific board was very slow,
> but I'm not sure yet.
> 
> And even in that case, I wonder how we should handle such a
> situation... I was thinking of adding a work-conserving mode, what do
> you think? You may have something similar in RT-Xen already but, even
> if you don't, there are a number of ways for achieving that without
> disrupting the real-time guarantees.
> 
> What do you think?
> 
>> If I understand correctly, the status in MAINTAINERS file should have
>> the highest priority and information from other sources should keep
>> updated with what the MAINTAINERS file says?
>>
>> Please correct me if I'm wrong.
>>
> This has been discussed before. Have a look at this thread/messages.
> 
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00972.html
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01775.html
> 
> And at this:
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html
> 
> The feature document template has been put together:
> http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01929.html
> 
> And there are feature documents in tree already.
> 
> Actually, writing one for RTDS would be a rather interesting and useful
> thing to do, IMO! :-)

I think it would be helpful to try to spell out what we think are the
criteria for marking RTDS non-experimental.  Reading your e-mail, Dario,
I might infer the following criteria:

1. New event-driven code spends most of a full release cycle in the tree
being tested
2. Better tests in osstest (which ones?)
3. A feature doc
4. A work-conserving mode

Is that about right?

#3 definitely sounds like a good idea.  #1 is probably reasonable.

I don't think #4 should be a blocker; we have plenty of work-conserving
schedulers. :-)

Regarding #2, did you have specific tests in mind?

Thoughts?

 -George

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

Re: [Xen-devel] [PATCH v2 for-4.7 14/14] tools/python: corrently use LDFLAGS and CFLAGS

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:23PM +0200, Roger Pau Monne wrote:
> It is incorrect to add the LDFLAGS to the CFLAGS, and some compilers will
> error out if linker flags are passed when creating object files. Fix this by
> properly passing CFLAGS and LDFLAGS, instead of putting everything in
> CFLAGS.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 for-4.7 13/14] oxenstored: fix error when shifting negative value

[Wei Liu]

The title is a bit too cryptic to me. Where do that shift happen?

Wei.

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

Re: [Xen-devel] [PATCH v9 13/27] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

[Jan Beulich]

>>> On 25.04.16 at 17:35,  wrote:
> v9: old_code and new_code are void, so drop the unsigned long cast
> and add void* - in both test-cases and document.
> Make tests target on ARM phony
> Add build dependencies on x86 build
> Include public/sysctl.h as CONFIG_XSPLICE may not be exposed.

Quite a bit better, albeit I don't really understand the reference to
CONFIG_XPLICE in this last bullet point. Irrespective of that

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 for-4.7 10/14] libxl: add the printf-like attributes to a couple of functions

[Andrew Cooper]

On 26/04/16 16:29, Wei Liu wrote:
> On Tue, Apr 26, 2016 at 04:52:19PM +0200, Roger Pau Monne wrote:
> [...]
>> @@ -1995,9 +1995,10 @@ _hidden libxl__json_object 
>> *libxl__json_parse(libxl__gc *gc_opt, const char *s);
>>  _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t 
>> domid);
>>/* Return the system-wide default device model */
>>  _hidden libxl_device_model_version libxl__default_device_model(libxl__gc 
>> *gc);
>> -_hidden char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t dm_domid,
>> -  uint32_t domid,
>> -  const char *format, ...) 
>> PRINTF_ATTRIBUTE(4, 5);
> Why does this not work with clang?

It is a security consideration.

Passing anything other than a string literal to a printf-style function
is opening a can of worms if an untrusted entity can influence the
content of the string.

I guess clang is better at spotting parameters passed like this than GCC.

~Andrew

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

Re: [Xen-devel] [PATCH V5] vm_event: Allow subscribing to write events for specific MSR-s

[Tamas K Lengyel]

> > @@ -55,6 +61,9 @@ void vm_event_cleanup_domain(struct domain *d)
> >  v->arch.vm_event = NULL;
> >  }
> >
> > +xfree(d->arch.monitor_msr_bitmap);
> > +d->arch.monitor_msr_bitmap = NULL;
> > +
> >  d->arch.mem_access_emulate_each_rep = 0;
> >  memset(&d->arch.monitor, 0, sizeof(d->arch.monitor));
> >  memset(&d->monitor, 0, sizeof(d->monitor));
>
> Aside from accidentally duplicating the alloc() / free() code here, I
> should have probably moved the following monitor-related memset()s in
> arch_monitor_init_domain() as well. I'll do that in V6.
>

Yes, +1 for moving the memsets to the new init function as well. It may be
cleaner if you break this patch into two, one where you introduce the new
monitor init and move these memsets there, and then do the msr patch.

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

Re: [Xen-devel] [PATCH v2 for-4.7 10/14] libxl: add the printf-like attributes to a couple of functions

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:19PM +0200, Roger Pau Monne wrote:
[...]
> @@ -1995,9 +1995,10 @@ _hidden libxl__json_object 
> *libxl__json_parse(libxl__gc *gc_opt, const char *s);
>  _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t 
> domid);
>/* Return the system-wide default device model */
>  _hidden libxl_device_model_version libxl__default_device_model(libxl__gc 
> *gc);
> -_hidden char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t dm_domid,
> -  uint32_t domid,
> -  const char *format, ...) 
> PRINTF_ATTRIBUTE(4, 5);

Why does this not work with clang?

Wei.

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

Re: [Xen-devel] [PATCH v2 for-4.7 09/14] xl: fix usage of libxl_get_scheduler

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:18PM +0200, Roger Pau Monne wrote:
> It returns an int, not a libxl_scheduler.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 

At the risk of nitpicking too much, I think we should enforce more
consistent style, especially in xl which is already quite messy at the
moment.

> ---
>  tools/libxl/xl_cmdimpl.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 8ff54e1..2ebca0a 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -5894,16 +5894,18 @@ static void output_xeninfo(void)
>  {
>  const libxl_version_info *info;
>  libxl_scheduler sched;
> +int sched_rc;
>  

CODING_STYLE says that variable holds return value of libxl API should
be rc, so sched_rc should be rc.

>  if (!(info = libxl_get_version_info(ctx))) {
>  fprintf(stderr, "libxl_get_version_info failed.\n");
>  return;
>  }
>  
> -if ((sched = libxl_get_scheduler(ctx)) < 0) {
> +if ((sched_rc = libxl_get_scheduler(ctx)) < 0) {
>  fprintf(stderr, "get_scheduler sysctl failed.\n");
>  return;
>  }
> +sched = sched_rc;
>  
>  printf("xen_major  : %d\n", info->xen_version_major);
>  printf("xen_minor  : %d\n", info->xen_version_minor);
> @@ -7991,7 +7993,7 @@ int main_cpupoolcreate(int argc, char **argv)
>  libxl_scheduler sched = 0;
>  XLU_ConfigList *cpus;
>  XLU_ConfigList *nodes;
> -int n_cpus, n_nodes, i, n;
> +int n_cpus, n_nodes, i, n, sched_rc;

Same here.

The code itself is fine.

Let me know if changing sched_rc to rc would cause a lot of troubles...

Wei.

>  libxl_bitmap freemap;
>  libxl_bitmap cpumap;
>  libxl_uuid uuid;
> @@ -8084,10 +8086,12 @@ int main_cpupoolcreate(int argc, char **argv)
>  goto out_cfg;
>  }
>  } else {
> -if ((sched = libxl_get_scheduler(ctx)) < 0) {
> +if ((sched_rc = libxl_get_scheduler(ctx)) < 0) {
>  fprintf(stderr, "get_scheduler sysctl failed.\n");
> +rc = EXIT_FAILURE;
>  goto out_cfg;
>  }
> +sched = sched_rc;
>  }
>  
>  if (libxl_get_freecpus(ctx, &freemap)) {
> -- 
> 2.6.4 (Apple Git-63)
> 

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

Re: [Xen-devel] [PATCH v2 for-4.7 09/14] xl: fix usage of libxl_get_scheduler

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> It returns an int, not a libxl_scheduler.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

[Jan Beulich]

>>> On 25.04.16 at 17:34,  wrote:
> +static int check_special_sections(const struct xsplice_elf *elf)
> +{
> +unsigned int i;
> +static const char *const names[] = { ELF_XSPLICE_FUNC };
> +bool_t count[ARRAY_SIZE(names)] = { 0 };
> +
> +for ( i = 0; i < ARRAY_SIZE(names); i++ )
> +{
> +const struct xsplice_elf_sec *sec;
> +
> +sec = xsplice_elf_sec_by_name(elf, names[i]);
> +if ( !sec )
> +{
> +dprintk(XENLOG_ERR, XSPLICE "%s: %s is missing!\n",
> +elf->name, names[i]);
> +return -EINVAL;
> +}
> +
> +if ( !sec->sec->sh_size )
> +{
> +dprintk(XENLOG_ERR, XSPLICE "%s: %s is empty!\n",
> +elf->name, names[i]);
> +return -EINVAL;
> +}
> +if ( ++count[i] > 1 )

boolean values can only validly be 0 or 1. Just "if ( count[i] )" here
and ...

> +{
> +dprintk(XENLOG_ERR, XSPLICE "%s: %s was seen more than once!\n",
> +elf->name, names[i]);
> +return -EINVAL;
> +}

"count[i] = 1;" here.

Thinking about it again, even more stack conserving would be a
bitmap...

> +static int apply_payload(struct payload *data)
> +{
> +unsigned int i;
> +
> +printk(XENLOG_INFO XSPLICE "%s: Applying %u functions\n",
> +data->name, data->nfuncs);
> +
> +arch_xsplice_patching_enter();
> +
> +for ( i = 0; i < data->nfuncs; i++ )
> +arch_xsplice_apply_jmp(&data->funcs[i]);
> +
> +arch_xsplice_patching_leave();
> +
> +list_add_tail_rcu(&data->applied_list, &applied_list);

Neither in the comment earlier on nor here it becomes clear that this
is more of an abuse than a use of RCU.

> +struct xsplice_patch_func {
> +const char *name;   /* Name of function to be patched. */
> +void *new_addr;
> +void *old_addr;
> +uint32_t new_size;
> +uint32_t old_size;
> +uint8_t version;/* MUST be XSPLICE_PAYLOAD_VERSION. */
> +uint8_t opaque[31]; /* MUST be zero filled. */

I don't see the zero filling being a requirement, nor it being enforced.

Jan


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

Re: [Xen-devel] [PATCH v2 for-4.7 08/14] libxl: fix shutdown_reason type in list_domains

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> It should be an enum, not an unsigned.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Doug Goldstein 

I had to drop the shutdown_reason >= 0 check a few lines below in my
version of this patch. But maybe its not necessary after all.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 08/14] libxl: fix shutdown_reason type in list_domains

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:17PM +0200, Roger Pau Monne wrote:
> It should be an enum, not an unsigned.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/xl_cmdimpl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 6346017..8ff54e1 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -4254,7 +4254,7 @@ static void list_domains(bool verbose, bool context, 
> bool claim, bool numa,
>  printf("\n");
>  for (i = 0; i < nb_domain; i++) {
>  char *domname;
> -unsigned shutdown_reason;
> +libxl_shutdown_reason shutdown_reason;
>  domname = libxl_domid_to_name(ctx, info[i].domid);
>  shutdown_reason = info[i].shutdown ? info[i].shutdown_reason : 0;
>  printf("%-40s %5d %5lu %5d %c%c%c%c%c%c  %8.1f",
> -- 
> 2.6.4 (Apple Git-63)
> 

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

Re: [Xen-devel] [PATCH v2 for-4.7 06/14] xen/tools: fix substitution of __align8__ uint64_t inside of headers

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> The current seedery doesn't work with BSD sed, so remove the try to match
> int64_t also (since there's none at the moment). Also, apply the same
> treatment to all arch headers, currently this is only done to x86_64
> headers.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 05/14] tools/headers: prevent adding two __align8__ to uint64_t in ARM headers

[Andrew Cooper]

On 26/04/16 15:52, Roger Pau Monne wrote:
> Due to the fact that on ARM headers types are substituted to uint64_t and
> then uint64_t is also substituted to contain the aligment, this would lead
> to some types containing two __align8__ directives. Fix this by first
> expanding Xen specific types to uint64_t only, and then replacing all the
> uint64_t types to __align8__ uint64_t. This relies on the fact that all
> Xen-specific types will have longer names, so they will always be replaced
> first.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 for-4.7 06/14] xen/tools: fix substitution of __align8__ uint64_t inside of headers

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:15PM +0200, Roger Pau Monne wrote:
> The current seedery doesn't work with BSD sed, so remove the try to match
> int64_t also (since there's none at the moment). Also, apply the same
> treatment to all arch headers, currently this is only done to x86_64
> headers.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 for-4.7 07/14] libxc: fix uninitialized variable

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:16PM +0200, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/xc_dom_bzimageloader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/xc_dom_bzimageloader.c 
> b/tools/libxc/xc_dom_bzimageloader.c
> index 7fde42a..0a4041c 100644
> --- a/tools/libxc/xc_dom_bzimageloader.c
> +++ b/tools/libxc/xc_dom_bzimageloader.c
> @@ -482,7 +482,7 @@ static int xc_try_lzo1x_decode(
>  if ( !dst_len )
>  {
>  msg = "Error registering stream output";
> -if ( xc_dom_register_external(dom, out_buf, out_len) )
> +if ( xc_dom_register_external(dom, out_buf, 0) )

I fail to figure out why this is correct.

I think the out_len should be moved out of the loop and initialise as 0.
We still need to use out_len here.

Wei.

>  break;
>  
>  return 0;
> -- 
> 2.6.4 (Apple Git-63)
> 

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

Re: [Xen-devel] [PATCH v2 for-4.7 05/14] tools/headers: prevent adding two __align8__ to uint64_t in ARM headers

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> Due to the fact that on ARM headers types are substituted to uint64_t and
> then uint64_t is also substituted to contain the aligment, this would lead
> to some types containing two __align8__ directives. Fix this by first
> expanding Xen specific types to uint64_t only, and then replacing all the
> uint64_t types to __align8__ uint64_t. This relies on the fact that all
> Xen-specific types will have longer names, so they will always be replaced
> first.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 05/14] tools/headers: prevent adding two __align8__ to uint64_t in ARM headers

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:14PM +0200, Roger Pau Monne wrote:
> Due to the fact that on ARM headers types are substituted to uint64_t and
> then uint64_t is also substituted to contain the aligment, this would lead
> to some types containing two __align8__ directives. Fix this by first
> expanding Xen specific types to uint64_t only, and then replacing all the
> uint64_t types to __align8__ uint64_t. This relies on the fact that all
> Xen-specific types will have longer names, so they will always be replaced
> first.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 for-4.7 03/14] build: pass HOST{CC/CXX} value down to Kconfig

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 
> Acked-by: Ian Jackson 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 11/14] libxl: add explicit casts from yajl_gen_status to yajl_status

[Wei Liu]

On Tue, Apr 26, 2016 at 04:52:20PM +0200, Roger Pau Monne wrote:
> Or else clang complains with:
> 
> implicit conversion from enumeration type 'yajl_gen_status' to different
> enumeration type 'yajl_status' [-Werror,-Wenum-conversion]
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxl/libxl_json.c | 29 ++---
>  1 file changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index 3b695dd..6bb0695 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -617,42 +617,48 @@ yajl_status libxl__json_object_to_yajl_gen(libxl__gc 
> *gc,
>  int idx = 0;
>  yajl_status rc;
>  
> +#define CONVERT_YAJL_GEN_TO_STATUS(gen) \
> +((gen) == yajl_gen_status_ok ? yajl_status_ok : yajl_status_error);
> +

Extraneous ";" at the end.

I can fix that up while committing.

Wei.

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

Re: [Xen-devel] [PATCH v2 for-4.7 06/14] xen/tools: fix substitution of __align8__ uint64_t inside of headers

[Andrew Cooper]

On 26/04/16 15:52, Roger Pau Monne wrote:
> The current seedery doesn't work with BSD sed, so remove the try to match
> int64_t also (since there's none at the moment). Also, apply the same
> treatment to all arch headers, currently this is only done to x86_64
> headers.
>
> Signed-off-by: Roger Pau Monné 

That is likely a side effect of me only getting the x86 bit of
tools+clang working.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 for-4.7 02/14] build: set HOSTCXX based on clang value for Kconfig xconfig target

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> The xconfig Kconfig target requires a C++ compiler because it uses Qt.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 01/14] build: make HOSTCC conditional on the value of clang

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> Previously HOSTCC was always hardcoded to gcc
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 03/14] build: pass HOST{CC/CXX} value down to Kconfig

[Andrew Cooper]

On 26/04/16 15:52, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 
> Acked-by: Ian Jackson 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 for-4.7 04/14] build: remove Kconfig forced gcc selection

[Andrew Cooper]

On 26/04/16 15:52, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 for-4.7 14/14] tools/python: corrently use LDFLAGS and CFLAGS

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> It is incorrect to add the LDFLAGS to the CFLAGS, and some compilers will
> error out if linker flags are passed when creating object files. Fix this by
> properly passing CFLAGS and LDFLAGS, instead of putting everything in
> CFLAGS.
> 
> Signed-off-by: Roger Pau Monné 
> ---

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.7 01/14] build: make HOSTCC conditional on the value of clang

[Andrew Cooper]

On 26/04/16 15:52, Roger Pau Monne wrote:
> Previously HOSTCC was always hardcoded to gcc
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 for-4.7 02/14] build: set HOSTCXX based on clang value for Kconfig xconfig target

[Andrew Cooper]

On 26/04/16 15:52, Roger Pau Monne wrote:
> The xconfig Kconfig target requires a C++ compiler because it uses Qt.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] How to install Xen on Fedora 23?

[Jason Long]

Hello.
I installed Fedora 23 x64 on my PC and id below command for installing Xen :

# cd /etc/yum.repos.d/
# wget http://fedorapeople.org/groups/virt/...t-preview.repo
# yum update
# yum -y install xen xen-hypervisor xen-libs xen-runtime
# systemctl enable xend.service
# systemctl enable xendomains.service

After it I run below command :

# grep ^menuentry /boot/grub2/grub.cfg | cut -d "'" -f2
Fedora (4.4.7-300.fc23.i686) 23 (Workstation Edition)
Fedora (4.2.3-300.fc23.i686) 23 (Workstation Edition)
Fedora (0-rescue-204e260309794cee901bd6e0b46ace3a) 23 (Workstation Edition)

But, I can't see any "Fedora, with Xen hypervisor" !!! and when I run "xl info" 
it show me below error :

# xl info
xc: error: Could not obtain handle on privileged command interface (2 = No such 
file or directory): Internal error
libxl: error: libxl.c:114:libxl_ctx_alloc: cannot open libxc handle: No such 
file or directory
cannot init xl context

How can I solve it?

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

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

[Jan Beulich]

>>> On 26.04.16 at 16:37,  wrote:
>>  -Original Message-
> [snip]
>> >> Apr 26 10:56:02.583602 (XEN)[]
>> >> hvm_mmio_internal+0x37/0x61
>> >
>> > Ah. Crap. I forgot about this path
>> 
>> So did I. And my testing didn't catch it because I have a post-4.7
>> patch in place avoiding registration of the vMSI-X handler when
>> there are no passed through devices, and on the box where I do
>> use pass-through I normally run with debug=n.
>> 
>> >   I think the best way round this is to have vmsi register as an full io
>> > interceptor so its accept method can use the passed in ioreq, which is 
> faked
>> > up to be a copy in this case. Either that or get rid of hvm_mmio_internal()
>> > altogether.
>> 
>> Getting rid of it is not possible afaict.
> 
> IIRC it's an optimization to avoid p2m lookups (or other overhead) that 
> would be pointless when the address is MMIO.

It's an optimization, yes, but one that is quite important for keeping
certain (iirc) Windows versions running even with reasonably high
vCPU counts.

> Perhaps this could be avoided in 
> another way e.g. by having certain emulators add their address ranges to a 
> list and checking against that instead?

That would be an option, but would duplicate state being tracked.

Jan


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

Re: [Xen-devel] [PATCH v2 for-4.7 04/14] build: remove Kconfig forced gcc selection

[Doug Goldstein]

On 4/26/16 9:52 AM, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Doug Goldstein 
> ---
>  xen/tools/kconfig/Makefile.kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/tools/kconfig/Makefile.kconfig 
> b/xen/tools/kconfig/Makefile.kconfig
> index 815f306..dbd8912 100644
> --- a/xen/tools/kconfig/Makefile.kconfig
> +++ b/xen/tools/kconfig/Makefile.kconfig
> @@ -36,8 +36,8 @@ KBUILD_DEFCONFIG := $(ARCH)_defconfig
>  CONFIG_SHELL := $(SHELL)
>  
>  # provide the host compiler
> -HOSTCC := gcc
> -HOSTCXX := g++
> +HOSTCC ?= gcc
> +HOSTCXX ?= g++
>  
>  # force target
>  PHONY += FORCE
> 

Acked-by: Doug Goldstein 

Regardless of the other patches in this series, this one should be
merged in.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/vMSI-X: write snoops should ignore hvm_mmio_internal() requests

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 April 2016 15:39
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Wei Liu
> Subject: [PATCH] x86/vMSI-X: write snoops should ignore
> hvm_mmio_internal() requests
> 
> Those aren't actual I/O requests (and hence are of no interest here
> anyway). Since they don't get copied into struct vcpu, looking at that
> copy reads whatever was left there. Use the state of the request to
> determine its validity.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> 
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -349,6 +349,8 @@ static int msixtbl_range(struct vcpu *v,
>  {
>  const ioreq_t *r = &v->arch.hvm_vcpu.hvm_io.io_req;
> 
> +if ( r->state != STATE_IOREQ_READY )
> +return 0;
>  ASSERT(r->type == IOREQ_TYPE_COPY);
>  if ( r->dir == IOREQ_WRITE && r->size == 4 && !r->data_is_ptr
>   && !(r->data & PCI_MSIX_VECTOR_BITMASK) )
> 
> 


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

[Xen-devel] [PATCH v2 for-4.7 11/14] libxl: add explicit casts from yajl_gen_status to yajl_status

[Roger Pau Monne]

Or else clang complains with:

implicit conversion from enumeration type 'yajl_gen_status' to different
enumeration type 'yajl_status' [-Werror,-Wenum-conversion]

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxl/libxl_json.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 3b695dd..6bb0695 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -617,42 +617,48 @@ yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
 int idx = 0;
 yajl_status rc;
 
+#define CONVERT_YAJL_GEN_TO_STATUS(gen) \
+((gen) == yajl_gen_status_ok ? yajl_status_ok : yajl_status_error);
+
 switch (obj->type) {
 case JSON_NULL:
-return yajl_gen_null(hand);
+return CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_null(hand));
 case JSON_BOOL:
-return yajl_gen_bool(hand, obj->u.b);
+return CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_bool(hand, obj->u.b));
 case JSON_INTEGER:
-return yajl_gen_integer(hand, obj->u.i);
+return CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_integer(hand, obj->u.i));
 case JSON_DOUBLE:
-return yajl_gen_double(hand, obj->u.d);
+return CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_double(hand, obj->u.d));
 case JSON_NUMBER:
-return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+return CONVERT_YAJL_GEN_TO_STATUS(
+  yajl_gen_number(hand, obj->u.string, strlen(obj->u.string)));
 case JSON_STRING:
-return libxl__yajl_gen_asciiz(hand, obj->u.string);
+return CONVERT_YAJL_GEN_TO_STATUS(
+libxl__yajl_gen_asciiz(hand, obj->u.string));
 case JSON_MAP: {
 libxl__json_map_node *node = NULL;
 
-rc = yajl_gen_map_open(hand);
+rc = CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_map_open(hand));
 if (rc != yajl_status_ok)
 return rc;
 for (idx = 0; idx < obj->u.map->count; idx++) {
 if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
 break;
 
-rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+rc = CONVERT_YAJL_GEN_TO_STATUS(
+libxl__yajl_gen_asciiz(hand, node->map_key));
 if (rc != yajl_status_ok)
 return rc;
 rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
 if (rc != yajl_status_ok)
 return rc;
 }
-return yajl_gen_map_close(hand);
+return CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_map_close(hand));
 }
 case JSON_ARRAY: {
 libxl__json_object *node = NULL;
 
-rc = yajl_gen_array_open(hand);
+rc = CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_array_open(hand));
 if (rc != yajl_status_ok)
 return rc;
 for (idx = 0; idx < obj->u.array->count; idx++) {
@@ -662,13 +668,14 @@ yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
 if (rc != yajl_status_ok)
 return rc;
 }
-return yajl_gen_array_close(hand);
+return CONVERT_YAJL_GEN_TO_STATUS(yajl_gen_array_close(hand));
 }
 case JSON_ANY:
 /* JSON_ANY is not a valid value for obj->type. */
 ;
 }
 abort();
+#undef CONVERT_YAJL_GEN_TO_STATUS
 }
 
 
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH v2 for-4.7 09/14] xl: fix usage of libxl_get_scheduler

[Roger Pau Monne]

It returns an int, not a libxl_scheduler.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxl/xl_cmdimpl.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 8ff54e1..2ebca0a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5894,16 +5894,18 @@ static void output_xeninfo(void)
 {
 const libxl_version_info *info;
 libxl_scheduler sched;
+int sched_rc;
 
 if (!(info = libxl_get_version_info(ctx))) {
 fprintf(stderr, "libxl_get_version_info failed.\n");
 return;
 }
 
-if ((sched = libxl_get_scheduler(ctx)) < 0) {
+if ((sched_rc = libxl_get_scheduler(ctx)) < 0) {
 fprintf(stderr, "get_scheduler sysctl failed.\n");
 return;
 }
+sched = sched_rc;
 
 printf("xen_major  : %d\n", info->xen_version_major);
 printf("xen_minor  : %d\n", info->xen_version_minor);
@@ -7991,7 +7993,7 @@ int main_cpupoolcreate(int argc, char **argv)
 libxl_scheduler sched = 0;
 XLU_ConfigList *cpus;
 XLU_ConfigList *nodes;
-int n_cpus, n_nodes, i, n;
+int n_cpus, n_nodes, i, n, sched_rc;
 libxl_bitmap freemap;
 libxl_bitmap cpumap;
 libxl_uuid uuid;
@@ -8084,10 +8086,12 @@ int main_cpupoolcreate(int argc, char **argv)
 goto out_cfg;
 }
 } else {
-if ((sched = libxl_get_scheduler(ctx)) < 0) {
+if ((sched_rc = libxl_get_scheduler(ctx)) < 0) {
 fprintf(stderr, "get_scheduler sysctl failed.\n");
+rc = EXIT_FAILURE;
 goto out_cfg;
 }
+sched = sched_rc;
 }
 
 if (libxl_get_freecpus(ctx, &freemap)) {
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH v2 for-4.7 05/14] tools/headers: prevent adding two __align8__ to uint64_t in ARM headers

[Roger Pau Monne]

Due to the fact that on ARM headers types are substituted to uint64_t and
then uint64_t is also substituted to contain the aligment, this would lead
to some types containing two __align8__ directives. Fix this by first
expanding Xen specific types to uint64_t only, and then replacing all the
uint64_t types to __align8__ uint64_t. This relies on the fact that all
Xen-specific types will have longer names, so they will always be replaced
first.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/include/xen-foreign/mkheader.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-foreign/mkheader.py 
b/tools/include/xen-foreign/mkheader.py
index 0504cb8..0e42e14 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -20,8 +20,8 @@ footer = {};
 inttypes["arm32"] = {
 "unsigned long" : "__danger_unsigned_long_on_arm32",
 "long"  : "__danger_long_on_arm32",
-"xen_pfn_t" : "__align8__ uint64_t",
-"xen_ulong_t"   : "__align8__ uint64_t",
+"xen_pfn_t" : "uint64_t",
+"xen_ulong_t"   : "uint64_t",
 "uint64_t"  : "__align8__ uint64_t",
 };
 header["arm32"] = """
@@ -41,8 +41,8 @@ footer["arm32"] = """
 inttypes["arm64"] = {
 "unsigned long" : "__danger_unsigned_long_on_arm64",
 "long"  : "__danger_long_on_arm64",
-"xen_pfn_t" : "__align8__ uint64_t",
-"xen_ulong_t"   : "__align8__ uint64_t",
+"xen_pfn_t" : "uint64_t",
+"xen_ulong_t"   : "uint64_t",
 "uint64_t"  : "__align8__ uint64_t",
 };
 header["arm64"] = """
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH v2 for-4.7 07/14] libxc: fix uninitialized variable

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/xc_dom_bzimageloader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxc/xc_dom_bzimageloader.c 
b/tools/libxc/xc_dom_bzimageloader.c
index 7fde42a..0a4041c 100644
--- a/tools/libxc/xc_dom_bzimageloader.c
+++ b/tools/libxc/xc_dom_bzimageloader.c
@@ -482,7 +482,7 @@ static int xc_try_lzo1x_decode(
 if ( !dst_len )
 {
 msg = "Error registering stream output";
-if ( xc_dom_register_external(dom, out_buf, out_len) )
+if ( xc_dom_register_external(dom, out_buf, 0) )
 break;
 
 return 0;
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH v2 for-4.7 04/14] build: remove Kconfig forced gcc selection

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Doug Goldstein 
---
 xen/tools/kconfig/Makefile.kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/tools/kconfig/Makefile.kconfig 
b/xen/tools/kconfig/Makefile.kconfig
index 815f306..dbd8912 100644
--- a/xen/tools/kconfig/Makefile.kconfig
+++ b/xen/tools/kconfig/Makefile.kconfig
@@ -36,8 +36,8 @@ KBUILD_DEFCONFIG := $(ARCH)_defconfig
 CONFIG_SHELL := $(SHELL)
 
 # provide the host compiler
-HOSTCC := gcc
-HOSTCXX := g++
+HOSTCC ?= gcc
+HOSTCXX ?= g++
 
 # force target
 PHONY += FORCE
-- 
2.6.4 (Apple Git-63)


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

[Xen-devel] [PATCH v2 for-4.7 14/14] tools/python: corrently use LDFLAGS and CFLAGS

[Roger Pau Monne]

It is incorrect to add the LDFLAGS to the CFLAGS, and some compilers will
error out if linker flags are passed when creating object files. Fix this by
properly passing CFLAGS and LDFLAGS, instead of putting everything in
CFLAGS.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/python/Makefile | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/python/Makefile b/tools/python/Makefile
index 2363537..da08f46 100644
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -4,7 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
-PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)
+PY_CFLAGS = $(CFLAGS) $(PY_NOOPT_CFLAGS)
+PY_LDFLAGS = $(LDFLAGS) $(APPEND_LDFLAGS)
 
 .PHONY: build
 build:
@@ -14,8 +15,9 @@ build:
 install:
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
 
-   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
-   $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force
+   CC="$(CC)" CFLAGS="$(PY_CFLAGS)" LDFLAGS="$(PY_LDFLAGS)" $(PYTHON) \
+   setup.py install $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)"  \
+   --force
 
$(INSTALL_PROG) scripts/convert-legacy-stream $(DESTDIR)$(LIBEXEC_BIN)
$(INSTALL_PROG) scripts/verify-stream-v2 $(DESTDIR)$(LIBEXEC_BIN)
-- 
2.6.4 (Apple Git-63)


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