flight 38092 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38092/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 13 guest-saverestore fail blocked in
37972
test-amd64-i3
This run is configured for baseline tests only.
flight 38091 xen-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-raw 3 host-install
As far as I can tell, Xen HVM domu guests detect and use the RTL8139 network
card thus its not a hard requirement to use the PVHVM drivers.
On EC2 however, am I right in understanding that although EC2 is using Xen HVM,
the RTL8139 network device is not available and therefore to get networking
flight 62481 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62481/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail REGR. vs. 62168
Regressions which
> +bool_t cdp_enabled = cdp_is_enabled(socket, cdp_socket_enable);
>
> if ( IS_ERR(info) )
> return PTR_ERR(info);
>
> -*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
> +switch ( type )
> +{
> +case PSR_CBM_TYPE_L3:
> +if ( type == PSR_CBM_TY
>
> +static inline bool_t cdp_is_enabled(unsigned int socket,
> +unsigned long *cdp_socket_enable)
Since cdp_socket_enable is defined in file scope, I don't think it's
required to pass again.
Chao
> +{
> +return cdp_socket_enable && test_bit(socket, cdp_
On Tue, Sep 29, 2015 at 02:47:39PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-28 at 16:29 +0800, He Chen wrote:
> > -"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
> > +"Platform Shared Resource Monitoring: Cache Monitoring Technology".
>
> I think these will clash w
On Tue, Sep 29, 2015 at 11:30:53AM +0100, Ian Campbell wrote:
> On Tue, 2015-09-29 at 10:33 +0100, Wei Liu wrote:
> > Now the reasoning bits. Yes, I'm arguing with myself, :-)
> >
> > We can of course fix it post-4.6, but the released APIs need to be
> > maintained forever (even if it is in fact b
On Tue, Sep 29, 2015 at 10:55:40AM +0100, Ian Campbell wrote:
> On Tue, 2015-09-29 at 10:27 +0100, Andrew Cooper wrote:
> > On 29/09/15 08:49, Chao Peng wrote:
> > > Drop the chapter number as it can be confusing when it gets changed in
> > > the referred document.
> > >
> > > Signed-off-by: Chao
flight 62475 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 62389
REGR. vs. 60727
Tes
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Tuesday, September 29, 2015 12:59 AM
> To: xen-devel
> Cc: George Dunlap; Andrew Cooper; Tian, Kevin; Keir Fraser; Nakajima, Jun
> Subject: Re: [Xen-de
HI Andy,
2015-09-29 18:06 GMT-04:00 Andy Smith :
> Hi Tianyang,
>
> On Mon, Sep 28, 2015 at 10:24:15PM -0400, soapcn wrote:
> > I keep getting this error about not being able to get domain type
> > when I try to create a domU.
> > Xen-4.7, Ubuntu 12.04
>
> I also had this problem recently with re
Andy, please reply to all in the future. You only replied to
xen-deve@ but didn't CC Tianyang.
On Tue, Sep 29, 2015 at 10:06:53PM +, Andy Smith wrote:
> Hi Tianyang,
>
> On Mon, Sep 28, 2015 at 10:24:15PM -0400, soapcn wrote:
> > I keep getting this error about not being able to get domain ty
flight 62468 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 2 hosts-allocatebroken REGR. vs. 59254
test-armhf-armhf-xl-x
On Tue, 2015-09-29 at 23:40 +0200, Dario Faggioli wrote:
> On Tue, 2015-09-29 at 18:31 +0100, Andrew Cooper wrote:
> > On 29/09/15 17:55, Dario Faggioli wrote:
> > Is the use of _lock_irq() here to cover another issue expecting
> > interrupts to be disabled, or could it be replaced with a plain
>
On Tue, 2015-09-29 at 18:31 +0100, Andrew Cooper wrote:
> On 29/09/15 17:55, Dario Faggioli wrote:
> > The insert_vcpu() scheduler hook is called with an
> > inconsistent locking strategy. In fact, it is sometimes
> > invoked while holding the runqueue lock and sometimes
> > when that is not the ca
Hi Tianyang,
On Mon, Sep 28, 2015 at 10:24:15PM -0400, soapcn wrote:
> I keep getting this error about not being able to get domain type
> when I try to create a domU.
> Xen-4.7, Ubuntu 12.04
I also had this problem recently with regard to some Ubuntu 12.04
domUs, but on Xen 4.4.1, Debian jessie.
Hi Ian,
On Tuesday, September 29, 2015 10:25:32 AM Ian Campbell wrote:
> On Mon, 2015-09-28 at 17:14 -0600, Mike Latimer wrote:
> > Any better options or ideas?
>
> Is part of the problem that shell is a terrible choice for this kind of
> check?
There is some truth to that... ;)
> Would shelli
flight 62463 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62463/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs.
Please avoid top-posting.
On Tue, Sep 29, 2015 at 01:43:29PM -0400, soapcn wrote:
> Andrew,
>
> Yes, the domain is constructed and I can see it using xl list command. As
> soon as I unpaused it, it crashed again.
>
You then need to figure out why it crashed. Maybe "xl dmesg" can give you
some i
Andrew,
Yes, the domain is constructed and I can see it using xl list command.
As soon as I unpaused it, it crashed again.
Tianyang
On 9/29/2015 9:00 AM, Andrew Cooper wrote:
On 29/09/15 13:54, Wei Liu wrote:
On Mon, Sep 28, 2015 at 10:24:15PM -0400, soapcn wrote:
[...]
domainbuilder: deta
On 29/09/15 17:55, Dario Faggioli wrote:
> The insert_vcpu() scheduler hook is called with an
> inconsistent locking strategy. In fact, it is sometimes
> invoked while holding the runqueue lock and sometimes
> when that is not the case.
>
> In other words, some call sites seems to imply that
> lock
On 29/09/15 18:17, Gohar Irfan wrote:
> What is the alternate of doing a malloc in Xen?
> I have a data structure (containing a list from the list.h implementation)
> and I want to initialize a pointer and allocate space for my struct. But
> since malloc doesn’t work in Xen, what should I do?
Us
On Tue, Sep 29, 2015 at 04:49:29PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> > diff --git a/cri-common b/cri-common
> > index c874ff9..66d13d1 100644
> > --- a/cri-common
> > +++ b/cri-common
> > @@ -79,6 +79,7 @@ select_xenbranch () {
> > > > ovmf)>
On Thu, Sep 17, 2015 at 10:54:23AM +0100, George Dunlap wrote:
[...]
> > Hi, George,
> >
> > I'm still confused about the expected look concerning PV/EMU type handling
> > in
> > this patch series.
> >
> > In earlier version, we tried to extract common things in libxl_usb.c and put
> > pvusb spe
What is the alternate of doing a malloc in Xen?
I have a data structure (containing a list from the list.h implementation) and
I want to initialize a pointer and allocate space for my struct. But since
malloc doesn’t work in Xen, what should I do?
Thanks
_
On Tue, Sep 29, 2015 at 04:43:50PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
>
> > + # Ignore these tests:
> > + #
> > tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
> > + # It try to start a guest with /de
From: Uma Sharma
Signed-off-by: Uma Sharma
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 46645f8..a28edd8 100644
--
Stefano Stabellini writes ("Re: [PATCH v7] run QEMU as non-root"):
> On Fri, 7 Aug 2015, Wei Liu wrote:
> > Please use for / while to loop.
>
> The goto retry loop is a very common patter for error handling, but I
> can turn it into a loop if you are keen on it.
I'm afraid I agree with Wei here.
Anthony PERARD writes ("Re: [PATCH OSSTEST v3 1/3] ts-openstack-deploy: Deploy
OpenStack on a host with devstack"):
> On Tue, Sep 29, 2015 at 04:34:44PM +0100, Ian Campbell wrote:
> > Maybe not because I don't see any calls to store_vcs_revision, which I
> > think we discussed on an earlier revisi
Ian Campbell writes ("Re: [PATCH OSSTEST v3 1/3] ts-openstack-deploy: Deploy
OpenStack on a host with devstack"):
> On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> > This script installs any necessary packages and clones all of the
> > OpenStack
> > trees which are used by devstack to d
El 29/09/15 a les 18.49, Roger Pau Monné ha escrit:
> El 29/09/15 a les 18.20, Jan Beulich ha escrit:
>> I said before that we should aim at being as
>> consistent as possible. (And btw I do not think that tr_base being
>> zero makes any sense.)
>
> We don't actually have a TSS anywhere, does it r
with the purpose of decoupling the allocation phase and
the initialization one, for per-pCPU data of the schedulers.
This makes it possible to perform the initialization later
in the pCPU bringup/assignement process, when more information
(for instance, the host CPU topology) are available. This,
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 75e0321..46645f8 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_
Anthony PERARD writes ("[PATCH OSSTEST v3 3/3] Create a flight to test
OpenStack with xen-unstable and libvirt"):
> Signed-off-by: Anthony PERARD
>
> ---
> Change in V3:
> - Switch to "track" Nova tree instead of devstack.
> Nova is the service we care about from a Xen point of view.
> A
On 29/09/15 17:21, Julien Grall wrote:
> All the quirks has been replaced by proper detection. Lets drop the
> callback and hope that no one will need new quirks.
>
> At the same time, remove the definition platform_dom0_evtchn_ppi with is
> not used any more.
>
> Signed-off-by: Julien Grall
> A
Hi everyone,
Code is already there, in the Credit2 scheduler, for setting up one runqueue
per each socket found in the system. However, that is not functional and only
one runqueue is being created, with all the pCPUs in it.
Some more details are available here:
http://lists.xen.org/archives/h
Experiments have shown that arranging the scheduing
runqueues on a per-core basis yields better results,
in most cases.
Such evaluation has been done, for the first time,
by Uma Sharma, during her participation to OPW. Some
of the results she got are summarized here:
http://lists.xen.org/archive
The credit2 scheduler tries to setup runqueues in such
a way that there is one of them per each socket. However,
that does not work. The issue is described in bug #36
"credit2 only uses one runqueue instead of one runq per
socket" (http://bugs.xenproject.org/xen/bug/36), and a
solution has been att
The .alloc_pdata hook of the scheduler interface is
called, in schedule_cpu_switch(), unconditionally,
for all schedulers.
This forces even schedulers that do not require any
actual allocation of per-pCPU data to:
- contain an implementation of the hook;
- return some artificial non-NULL value t
by borrowing some of the code of .alloc_pdata, i.e.,
the bits that perform initializations, leaving only
actual allocations in there, when any, which is the
case for Credit1 and RTDS.
On the other hand, in Credit2, since we don't really
need any per-pCPU data allocation, everything that was
being
In fact, credit2 uses CPU topology to decide how to arrange
its internal runqueues. Before this change, only 'one runqueue
per socket' was allowed. However, experiments have shown that,
for instance, having one runqueue per physical core improves
performance, especially in case hyperthreading is av
The insert_vcpu() scheduler hook is called with an
inconsistent locking strategy. In fact, it is sometimes
invoked while holding the runqueue lock and sometimes
when that is not the case.
In other words, some call sites seems to imply that
locking should be handled in the callers, in schedule.c
--
On Tue, Sep 29, 2015 at 12:59 PM, Hamed Rs wrote:
> Is it possible to write to file from xen kernel?
Not directly -- Xen doesn't manage any disks itself.
It is fairly common for Xen to store data in a buffer, and have dom0
read the buffer and write it to disk. xentrace is an example of that
sor
El 29/09/15 a les 18.20, Jan Beulich ha escrit:
On 29.09.15 at 18:01, wrote:
>> El 29/09/15 a les 17.29, Jan Beulich ha escrit:
>> On 29.09.15 at 16:01, wrote:
Ok thanks, so we seem to have a consensus. Before posting a new
revision, does the following vcpu_hvm_context look fi
On Fri, 7 Aug 2015, Wei Liu wrote:
> On Thu, Jul 23, 2015 at 06:08:02PM +0100, Stefano Stabellini wrote:
> [...]
> > +For security reasons, libxl tries to pass a non-root username to QEMU as
> > +argument. During initialization QEMU calls setuid and setgid with the
> > +user ID and the group ID of
On Mon, Sep 28, 2015 at 3:30 PM, Jan Beulich wrote:
> Now that p2m->get_entry() always returns a valid order, utilize this
> to accelerate some of the operations in PoD code. (There are two uses
> of p2m->get_entry() left which don't easily lend themselves to this
> optimization.)
>
> Also adjust
The field value is only used within a single function in the vgic-v2
emulation. So it's not necessary to store the value in the domain
structure.
This is also saving 8 bytes on a structure which begin to be constrained
(the maximum size of struct domain is 4KB).
Signed-off-by: Julien Grall
Acked
Xen is unconditionally using certain device tree paths to create DOM0
specific node (for instance /psci, /memory and /hypervisor).
Print a warning message on the console to let the user know if we
re-use one of these nodes.
Note that the content of most of those is very common and they
should hav
The callback make_hwdom_dt_node already has the GIC node in parameter.
Rather than using a weird mix between "dt_interrupt_controller" (aliased
to "gic") and "node", rename the callback parameter "node" to "gic" and
remove local GIC definitions in terms of the global
dt_interrupt_interrupt_control
Free the memory used for the compressed kernel and update the relative
mod->start and mod->size parameters with the uncompressed ones.
To decompress the kernel, allocate memory from dommheap, because freeing
the modules is done by calling init_heap_pages, which frees to domheap.
Map these pages us
Ian Campbell writes ("Re: [OSSTEST PATCH 7/7] ts-debian-fixup: Install the
overlays"):
> On Tue, 2015-09-29 at 14:37 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
>
> Acked-by: Ian Campbell
>
> I'm not especially sure it is necessary to stash the tarball, we don't for
> HVM or other
El 29/09/15 a les 17.29, Jan Beulich ha escrit:
On 29.09.15 at 16:01, wrote:
>> Ok thanks, so we seem to have a consensus. Before posting a new
>> revision, does the following vcpu_hvm_context look fine to both of you:
>>
>> struct vcpu_hvm_x86_32 {
>> uint32_t eax;
>> uint32_t ecx;
>>> On 29.09.15 at 18:01, wrote:
> El 29/09/15 a les 17.29, Jan Beulich ha escrit:
> On 29.09.15 at 16:01, wrote:
>>> Ok thanks, so we seem to have a consensus. Before posting a new
>>> revision, does the following vcpu_hvm_context look fine to both of you:
>>>
>>> struct vcpu_hvm_x86_32 {
>
guest_var would check GUEST_VN and guests_VN. target_var_prefix would
return GUEST_ or `' (for a host), but can only be sensibly used for
setting, not getting (since a getter ought to check guests_VN as well).
But we might want to be able to set different runvars for different
hosts, so we would
On Tue, Sep 29, 2015 at 04:34:44PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> > This script installs any necessary packages and clones all of the
> > OpenStack
> > trees which are used by devstack to deploy OpenStack.
> >
> > Signed-off-by: Anthony PERA
target_kernkind_console_inittab is supposed to edit inittab to make
sure that there is a getty running on hvc0.
However:
- It is not idempotent; if run more than once it can produce duplicate
entries `1:' and `xc:'.
- It works by copying and editing the entry `1:' but it might be that
ther
There are two patches here to fix annoyances which can make
osstest-installed Debian guests hard to get into.
And two patches to reorganise slightly the runvar handling:
introducing a function `target_var' to replace `guest_var'. Currently
there is no real motivation for this except that it seems
Previously this script would try to set an empty password. However,
default installs have a configuration which hates empty passwords.
Instead, set the password `xenroot'. The value is the output of:
perl -e '$x = crypt "xenroot", "aa"; print "$x\n"'
Signed-off-by: Ian Jackson
---
ts-debian
This abstracts away a number of places that do
guest_var($gho,'FOO',$r{xen_FOO})
We are going to change these runvar names.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm |8
ts-debian-install |6 +++---
ts-logs-capture|2 +-
3 files changed, 12 insert
On 29/09/15 17:33, Julien Grall wrote:
> Hi David,
>
> On 29/09/15 17:27, David Vrabel wrote:
>> On 07/09/15 16:33, Julien Grall wrote:
>>>
>>> A branch based on the latest xentip/for-linus-4.3 can be found here:
>>>
>>> git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v4
>>
>> Th
Hi all,
Only patch #7 is related to the subject of the cover letter. The rest is
clean up of code I looked while I was working on this patch series.
For all the changes, see in each patch.
Sincerely yours,
Julien Grall (7):
xen/arm: gic: Make it clear the GIC node is passed to
make_hwdom_
We want debootstrap-installed guests to get these overlays too.
Signed-off-by: Ian Jackson
---
v2: Use a tmpfile rather than a stashfile for the tarball.
---
ts-debian-fixup | 13 +
1 file changed, 13 insertions(+)
diff --git a/ts-debian-fixup b/ts-debian-fixup
index 6d24587..75c9
The functions dt_n_*_cells return the number of cells for a "reg"
property of a given node. So those numbers won't be correct if the
parent of a given node is passed.
This is fine today because the parent is always the root node which
means there is no upper parent.
Introduce new helpers dt_child
The size of the CPU interface will used in a follow-up patch to map the
region in Xen memory.
Based on GICv2 spec, the CPU interface should at least be 8KB, although
most of the platform we are supporting use incorrectly the GICv1 size
(i.e 4KB) in their DT. Only warn and update the size to avoid
We are currently using a per-platform quirk to know if the 2 4KB region of
the GIC CPU interface are each aligned to 64KB. Although, it may be
possible to have different layout on a same platform (depending on the
firmware version).
Rather than having a quirk it's possible to detect by reading the
All the quirks has been replaced by proper detection. Lets drop the
callback and hope that no one will need new quirks.
At the same time, remove the definition platform_dom0_evtchn_ppi with is
not used any more.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
Ian Campbell writes ("Re: [OSSTEST PATCH 3/1] ts-hosts-allocate-Executive:
Print more info about booking to main log"):
> On Tue, 2015-09-29 at 16:27 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson
> > + push @{ $prstart{ $book->{Start }} }, $pr;
>
>
Ian Campbell writes ("Re: [PATCH OSSTEST v5] Add arm64 build and test jobs"):
> Not quite, since the arm32 and arm64 h/w is distinct. These tests won't run
> on any of the arm32 hardware we have and the existing armhf tests won't run
> on the new hwardware (for reasons I'll hopefully explain in the
>>> On 29.09.15 at 16:01, wrote:
> Ok thanks, so we seem to have a consensus. Before posting a new
> revision, does the following vcpu_hvm_context look fine to both of you:
>
> struct vcpu_hvm_x86_32 {
> uint32_t eax;
> uint32_t ecx;
> uint32_t edx;
> uint32_t ebx;
> uint32_t
On Tue, 2015-09-29 at 16:27 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> ---
> Osstest/Executive.pm | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
> index aeb8c25..3475862 100644
> --- a/Osstest/Exec
Ian Campbell writes ("Re: [OSSTEST PATCH] ts-hosts-allocate-Executive: Do not
allocate specific host with wrong blessing"):
> On Tue, 2015-09-29 at 15:14 +0100, Ian Jackson wrote:
> > If the job contains a runvar specifying a specific host, still check
> > that host's blessing. Otherwise bisectio
Hi David,
On 29/09/15 17:27, David Vrabel wrote:
> On 07/09/15 16:33, Julien Grall wrote:
>>
>> A branch based on the latest xentip/for-linus-4.3 can be found here:
>>
>> git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v4
>
> This has too many conflicts with the
> git://git.kern
Ian Campbell writes ("[PATCH OSSTEST v5] Add arm64 build and test jobs"):
> Runvars for the xen-unstable flight build jobs and an illustrative test:
...
Reading this again:
This is approximately doubling our ARM test bandwidth requirements,
isn't it ?
> test-arm64-arm64-libvirt
> test-arm64-arm6
On Tue, Sep 29, 2015 at 03:37:06PM +0100, Ian Campbell wrote:
> On Tue, 2015-09-29 at 22:01 +0800, Haozhong Zhang wrote:
> > On Tue, Sep 29, 2015 at 02:56:12PM +0100, Andrew Cooper wrote:
> > > On 29/09/15 14:53, Haozhong Zhang wrote:
> > > > On Tue, Sep 29, 2015 at 11:28:38AM +0100, Ian Campbell w
Runvars for the xen-unstable flight build jobs and an illustrative test:
build-arm64 arch
arm64
build-arm64 build_lvextend_max
50
build-arm64
This run is configured for baseline tests only.
flight 38089 xen-4.2-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38089/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-i386-i386-libvirt-raw6 xen-boot
On 28 Sep 2015, at 15:29, Andrew Cooper wrote:
>> In case it’s all stored in the boot node, and dom0’s memory is also
>> contained entirely in the same node, is it correct to say that a failure in
>> another node would just require to shut down the VMs that are running in
>> that node but the
On Tue, 2015-09-29 at 16:27 +0100, Ian Jackson wrote:
> Call $equivflagscheckq->finish() at the end, rather than in the
> candidate search loop. This avoids missing a `next' control path.
>
> Call $resprop_q->finish() at all.
>
> One of these is responsible for this message:
>
> DBI::db=HASH(
On 07/09/15 16:33, Julien Grall wrote:
>
> A branch based on the latest xentip/for-linus-4.3 can be found here:
>
> git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v4
This has too many conflicts with the
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.4
br
flight 62537 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62537/
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
The current gunzip code to decompress the Dom0 kernel is implemented in
inflate.c which is included by bzimage.c.
I am looking to doing the same on ARM64 but there is quite a bit of
boilerplate definitions that I would need to import in order for
inflate.c to work correctly.
Instead of copying/pa
On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> + # Ignore these tests:
> + #
> tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
> + # It try to start a guest with /dev/vda as boot device name.
> + $ignored_tests .= '|.*TestVolumeBootPatter
On Tue, 2015-09-29 at 16:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v5] Add arm64 build and test jobs"):
> > Runvars for the xen-unstable flight build jobs and an illustrative
> > test:
> ...
>
> Reading this again:
>
> This is approximately doubling our ARM test bandwidt
On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> This script installs any necessary packages and clones all of the
> OpenStack
> trees which are used by devstack to deploy OpenStack.
>
> Signed-off-by: Anthony PERARD
This mostly looks good to me. A few comments.
> + # libvirt is alre
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index aeb8c25..3475862 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -743,9 +743,19 @@ sub alloc_res
On 30/07/15 18:03, David Vrabel wrote:
> The series improves the use of hotplug memory in the Xen balloon
> driver.
>
> - Reliably find a non-conflicting location for the hotplugged memory
> (this fixes memory hotplug in a number of cases, particularly in
> dom0).
>
> - Use hotplugged memory
Call $equivflagscheckq->finish() at the end, rather than in the
candidate search loop. This avoids missing a `next' control path.
Call $resprop_q->finish() at all.
One of these is responsible for this message:
DBI::db=HASH(0x88e79c4)->disconnect invalidates 1 active statement
handle (either
Hi all,
this patch series introduces support for gzipped kernels, such as the
standard Image.gz format used by Linux on arm64 by default, in Xen on
arm. Without it, Xen cannot load the default kernel shipped by distros,
such as CentOS 7.
Stefano Stabellini (2):
xen: move perform_gunzip to
On Mon, 2015-09-28 at 16:56 +0100, Anthony PERARD wrote:
> diff --git a/cri-common b/cri-common
> index c874ff9..66d13d1 100644
> --- a/cri-common
> +++ b/cri-common
> @@ -79,6 +79,7 @@ select_xenbranch () {
> >> ovmf)>> > > tree=ovmf;> >
> xenbranch=xen-unstable ;;
> >
Ian Campbell writes ("Re: [PATCH OSSTEST 3/6] Debian: uboot: Use di_vg_name()
and lv_dev_mapper() for root="):
> On Tue, 2015-09-29 at 15:08 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST 3/6] Debian: uboot: Use di_vg_name()
> > and lv_dev_mapper() for root="):
> > > root is no
Ian Campbell writes ("Re: [PATCH OSSTEST 1/3] standalone: Add get-job-status to
pick status out of standalone.db"):
> If cs-job-status still seems useful then I can certainly add that. I'd
> probably keep the convenience wrapper in standalone unless you object.
Right. Yes, I think cs-job-status
On Tue, 2015-09-29 at 15:46 +0100, Stefano Stabellini wrote:
> On Tue, 29 Sep 2015, Ian Campbell wrote:
> > On Wed, 2015-09-23 at 19:31 +0100, Stefano Stabellini wrote:
> > > [/...]
> > > +
> > > +/*
> > > + * Need to free pages after output_size here because they won't
> > > be
> > > +
On Mon, Sep 28, 2015 at 4:16 AM, Razvan Cojocaru
wrote:
> A previous version of this patch dealing with support for skipping
> the current instruction when a vm_event response requested it
> computed the instruction length in the hypervisor, adding non-trivial
> code dependencies. This patch allo
On Tue, 29 Sep 2015, Ian Campbell wrote:
> On Wed, 2015-09-23 at 19:31 +0100, Stefano Stabellini wrote:
> > [/...]
> > +
> > +/*
> > + * Need to free pages after output_size here because they won't be
> > + * freed by discard_initial_modules
> > + */
> > +i = (output_size + PAG
Some handlers may require to use private data in order to get quickly
information related to the region emulated.
Signed-off-by: Julien Grall
---
Cc: shameerali.kolothum.th...@huawei.com
This will be necessary in the follow-up in order to fix bug in the
GICR emulation.
Changes in
The field names in the IO emulation are really long and use repeatedly
the term handler which make some line cumbersome to read:
mmio_handler->mmio_handler_ops->write_handler
Also take the opportunity to do some clean up:
- Avoid "handler" vs "handle" in register_mmio_handler
- Use a loca
Hi,
This small patch series aims to fix the issue discovered by Shameerali when
booting Xen on his platform.
Note the last patch is just a clean-up because I was bothered with the really
long name in the I/O emulation. It has been placed at the end sow e can
backport easily the first 2 patches in
When the guest is accessing the re-distributor, Xen retrieves the base
of the re-distributor using a mask based on the stride.
When the stride contains multiple bits set, the corresponding mask will be
computed incorrectly [1] and therefore giving invalid vCPU and offset:
(XEN) d0v0: vGICR: unkno
On 24/09/15 04:40, Dario Faggioli wrote:
> and of (almost every) direct use of cpupool_online_cpumask().
>
> In fact, what we really want for the most of the times,
> is the set of valid pCPUs of the cpupool a certain domain
> is part of. Furthermore, in case it's called with a NULL
> pool as argu
1 - 100 of 283 matches
Mail list logo
