flight 62696 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 62649
Regressions which a
>>> On 07.10.15 at 19:45, wrote:
> OK, so we have to decide on a *set* of factors, rather than just one.
>
> Let's try to be analytic.
>
> So we have so far identified 4 "parameters" that we can tweak:
>
> 1. Release frequency. At the moment, this is "9 months".
> 2. Length of time bug fixes a
>>> On 07.10.15 at 19:56, wrote:
> On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote:
> On 06.10.15 at 13:07, wrote:
>>> A majority of developers express interests in trying a shorter release
>>> cycle -- to change from 9 months to 6 months [0]. There are, however,
>>> repercussions on how w
On Mon, 2015-09-28 at 04:48 +, osstest service owner wrote:
> Tests which did not succeed, but are not blocking:
>
[...]
> build-amd64-prev 5 xen-buildfail never
> pass
> build-i386-prev 5 xen-buildfail never
> pass
T
>>> On 07.10.15 at 19:02, wrote:
> __scheme A__
> Q1: - when to take the references?
> take the reference when the IOMMU entry is _created_;
> in detail:
> --iommu_map_page(), or
> --ept_set_entry() [Once IOMMU shares EPT page table.]
>
> That leaves one question:
> -- how t
El 07/10/15 a les 16.01, Andrew Cooper ha escrit:
> On 07/10/15 14:32, George Dunlap wrote:
>> On 07/10/15 12:55, Roger Pau Monné wrote:
>>> El 06/10/15 a les 13.05, George Dunlap ha escrit:
On 05/10/15 10:34, Andrew Cooper wrote:
> On 02/10/15 16:48, Roger Pau Monne wrote:
>> Introduc
On Wed, 2015-10-07 at 18:55 +0200, Roger Pau Monne wrote:
> Introduce a very simple (and dummy) domain loader to be used to load the
> firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
> executable the loader is fairly simple.
>
> Since the order in which loaders are tested
El 08/10/15 a les 11.22, Ian Campbell ha escrit:
> On Wed, 2015-10-07 at 18:55 +0200, Roger Pau Monne wrote:
>> Introduce a very simple (and dummy) domain loader to be used to load the
>> firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
>> executable the loader is fairly si
flight 62700 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62700/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeatfail like 60696
test-amd64-amd64-xl-qemuu-
On 08/10/15 06:05, Juergen Gross wrote:
> On 10/07/2015 10:21 PM, Konrad Rzeszutek Wilk wrote:
>> Hey,
>>
>> I was running some tools in which we would heavily do rescheduling
>> of events - and realized to my surprise that the event channels (and
>> the hypercall) would slow things down. If I used
On Wed, 2015-10-07 at 20:13 +0100, Julien Grall wrote:
> On 07/10/15 17:29, Julien Grall wrote:
> > TBH, I don't see how I can justify that what we are doing is fine except
> > by saying "for simplicity".
I think it is also fine to say that we currently expect that in reality
OSes won't rely on be
flight 62701 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62701/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-i
On Wed, 2015-10-07 at 18:55 +0200, Roger Pau Monne wrote:
> Introduce a very simple (and dummy) domain loader to be used to load the
> firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
> executable the loader is fairly simple.
>
> Since the order in which loaders are tested
Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v3 02/22] tools: Refactor
"xentoollog" into its own library"):
> On Wed, 2015-10-07 at 15:42 +0100, Andrew Cooper wrote:
...
> > Installation of all .so's needs to be conditional on $(nosharedlibs) to
> > match the condition in the build rule.
>
>
>>> On 02.10.15 at 17:48, wrote:
> @@ -517,6 +520,22 @@ int arch_domain_create(struct domain *d, unsigned int
> domcr_flags,
> d->domain_id);
> }
>
> +if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
> +{
> +printk(XENLOG_G_ERR "d%d: Invalid emulatio
That is, jobs which are building xen-4.3-testing, where ovmf was not
yet supported.
Full diff to standalone-generate-dump-flight-runvars is:
$ diff -u BEFORE AFTER
--- BEFORE 2015-10-08 10:30:04.860534748 +0100
+++ AFTER 2015-10-08 11:21:21.618731064 +0100
@@ -17283,11 +17283,11 @@
xe
And use this in standalone-generate-dump-flight-runvars. In general I
don't think we are interested in the specific revision_* runvars when
using this tool and this is quicker even than using memoisation on the
ap-fetch invocations. This produces output like:
libvirtbuild-amd64
>>> On 24.09.15 at 10:02, wrote:
On 23.09.15 at 19:37, wrote:
>> On 22/09/15 14:06, Jan Beulich wrote:
>>> ... in anticipation of this possibly going to get used by guests for
>>> basic thinks like memset() or clearing or pages.
>>>
>>> Since the emulation doesn't use clzero itself, checking
Otherwise:
Use of uninitialized value in string eq at Osstest/Debian.pm line 410.
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index bd482d6..5b26c4f 100644
--- a/Osstest/Debian.pm
+++
By editing /etc/default/grub in a late command iff it exists.
This will effect ts-debian-{hvm,di}-install as well as
ts-host-install and hence effect guests as well as hosts.
The overall effect is that we will log more upon guest boot as well as
on the initial host boot.
Note that for hosts we a
El 08/10/15 a les 12.23, Jan Beulich ha escrit:
On 02.10.15 at 17:48, wrote:
>> @@ -517,6 +520,22 @@ int arch_domain_create(struct domain *d, unsigned int
>> domcr_flags,
>> d->domain_id);
>> }
>>
>> +if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
>> +
He Chen writes ("[PATCH v6 3/3] tools & docs: add tools and docs support for
Intel CDP"):
> This is the xl/xc changes to support Intel Code/Data Prioritization.
> CAT xl commands to set/get CBMs are extended to support CDP.
> Add new CDP options with CAT commands in xl interface man page.
> Add de
>>> On 02.10.15 at 17:48, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2412,7 +2412,8 @@ static void vmx_install_vlapic_mapping(struct vcpu *v)
> {
> paddr_t virt_page_ma, apic_page_ma;
>
> -if ( !cpu_has_vmx_virtualize_apic_accesses )
> +if (
On 08/10/15 09:05, Jan Beulich wrote:
On 07.10.15 at 19:45, wrote:
>> OK, so we have to decide on a *set* of factors, rather than just one.
>>
>> Let's try to be analytic.
>>
>> So we have so far identified 4 "parameters" that we can tweak:
>>
>> 1. Release frequency. At the moment, this is
flight 62707 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62707/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 60684
build-amd6
El 08/10/15 a les 12.12, Ian Campbell ha escrit:
> On Wed, 2015-10-07 at 18:55 +0200, Roger Pau Monne wrote:
>> Introduce a very simple (and dummy) domain loader to be used to load the
>> firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
>> executable the loader is fairly si
On 08/10/15 10:39, Ian Campbell wrote:
> On Wed, 2015-10-07 at 20:13 +0100, Julien Grall wrote:
>> On 07/10/15 17:29, Julien Grall wrote:
>>> TBH, I don't see how I can justify that what we are doing is fine except
>>> by saying "for simplicity".
>
> I think it is also fine to say that we currentl
Hi Ian,
It looks like there is only comment on patch #7. Would it be possible to
apply #1-#6? I will resend the last 3 patches after I agree with Stefano
about the chosen behavior in #7.
Regards,
On 07/10/15 15:41, Julien Grall wrote:
> Hi all,
>
> This series aims to fixc the 32-bit access on
On Thu, 2015-10-08 at 11:23 +0800, He Chen wrote:
> This is the xl/xc changes to support Intel Code/Data Prioritization.
> CAT xl commands to set/get CBMs are extended to support CDP.
> Add new CDP options with CAT commands in xl interface man page.
> Add description of CDP in xl-psr.markdown.
>
>
On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
> Furthermore, based on the spec (4.3.12 in IHI 0048B.b): "A register
> field corresponding to an unimplemented interrupt is RAZ/WI."
>
> If the user knows that an interrupt is not implemented, he may decide to
> write 0 in the corresponding
Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
> What I consider more of an issue is the tedious (because purely
> mechanical) task of committing the patches to the respective stable
> trees, which (in my way of doing it) implies test builds for every
> commit. This is
On Thu, 2015-10-08 at 12:43 +0200, Roger Pau Monné wrote:
> > However I'm unsure that the presence or absence of ELF notes is sufficient,
> > since there is at least the legacy SHT_NOTE section and then __xen_guest
> > section (see the tail of elf_xen_parse) as well.
>
> AFAICT NetBSD still uses t
On 08/10/15 09:05, Jan Beulich wrote:
>> It has so far been assumed in this discussion that this would be an
>> undue burden, and therefore not acceptable.
>
> I don't think anyone said "undue". All that was said was that the
> amount of work to be put into this increases.
I think it's worth sayi
On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
> >>> On 07.10.15 at 19:45, wrote:
[...]
>
> > But it's worth asking
> > whether that is actually the case. It has been argued, for instance,
> > that the difficulty in backporting a patch scales with the distance in
> > commits that
On 08/10/15 12:04, Ian Campbell wrote:
> On Thu, 2015-10-08 at 12:43 +0200, Roger Pau Monné wrote:
>>> However I'm unsure that the presence or absence of ELF notes is sufficient,
>>> since there is at least the legacy SHT_NOTE section and then __xen_guest
>>> section (see the tail of elf_xen_parse)
On Thu, Oct 08, 2015 at 12:04:30PM +0100, Ian Campbell wrote:
> On Thu, 2015-10-08 at 12:43 +0200, Roger Pau Monné wrote:
> > > However I'm unsure that the presence or absence of ELF notes is
> > > sufficient,
> > > since there is at least the legacy SHT_NOTE section and then __xen_guest
> > > sec
Ian Campbell writes ("[PATCH XEN v3 01/22] tools/Rules.mk: Properly handle
libraries with recursive dependencies."):
> In tree libraries which link against other in tree libraries in a way
> which is opaque to their callers need special handling, specifically
> correct use of -Wl,-rpath-link for t
Ian Campbell writes ("[PATCH XEN v3 02/22] tools: Refactor "xentoollog" into
its own library"):
> In attempting to disaggregate libxenctrl I found that many of the
> pieces were going to want access to this library, so split it out (as
> it probably should always have been).
>
> Various build adj
Ian Campbell writes ("[PATCH QEMU-XEN-TRADITIONAL v3 1/5] qemu-xen-traditional:
Use xentoollog as a separate library"):
> This has been split out of libxenctrl, so the build needs to be able
> to find the header and the library. QEMU does not use xtl_* itself so
> -rpath-link is sufficient to allo
>>> On 08.10.15 at 12:59, wrote:
> Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
>> Perhaps there's room for further automation here, yet as with
>> any automation the question is how quickly getting this in place
>> will amortize itself.
>
> Even with the current sit
On Thu, 2015-10-08 at 12:23 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH XEN v3 02/22] tools: Refactor "xentoollog"
> into its own library"):
> > In attempting to disaggregate libxenctrl I found that many of the
> > pieces were going to want access to this library, so split it out (as
>
On Thu, 2015-10-08 at 12:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH XEN v3 01/22] tools/Rules.mk: Properly
> handle libraries with recursive dependencies."):
> > In tree libraries which link against other in tree libraries in a way
> > which is opaque to their callers need special
On Thu, 8 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
>
> > Furthermore, based on the spec (4.3.12 in IHI 0048B.b): "A register
> > field corresponding to an unimplemented interrupt is RAZ/WI."
> >
> > If the user knows that an interrupt is not implement
On Thu, 2015-10-08 at 11:44 +0100, Julien Grall wrote:
> Hi Ian,
>
> It looks like there is only comment on patch #7. Would it be possible to
> apply #1-#6?
Done.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, 2015-10-02 at 17:48 +0200, Roger Pau Monne wrote:
> This series is split in the following order:
>
> - Patches from 2 to 11 switch HVM domain contruction to use the xc_dom_*
>family of functions, like they are used to build PV domains. This batch
>of patches can go in regardless o
On Thu, 2015-10-08 at 12:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH QEMU-XEN-TRADITIONAL v3 1/5] qemu-xen
> -traditional: Use xentoollog as a separate library"):
> > This has been split out of libxenctrl, so the build needs to be able
> > to find the header and the library. QEMU do
>>> On 08.10.15 at 12:39, wrote:
> On 08/10/15 09:05, Jan Beulich wrote:
> On 07.10.15 at 19:45, wrote:
>>> The steady state for "R9 S3 {18,36}" is to have 2 releases receiving
>>> bug fixes, and 2 releases receiving security fixes at any given time;
>>> and this happens every 3 months; total
On 10/08/2015 01:34 PM, Jan Beulich wrote:
On 08.10.15 at 12:59, wrote:
Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
Perhaps there's room for further automation here, yet as with
any automation the question is how quickly getting this in place
will amortize itself
>>> On 08.10.15 at 13:10, wrote:
> On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
>> Perhaps there's room for further automation here, yet as with
>> any automation the question is how quickly getting this in place
>> will amortize itself.
>>
>
> Building every commit can be easily
flight 62729 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62729/
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
This run is configured for baseline tests only.
flight 38135 linux-3.16 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38135/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-credit2 18 guest-localmigrate/x10
>>> On 08.10.15 at 13:49, wrote:
> On 10/08/2015 01:34 PM, Jan Beulich wrote:
> On 08.10.15 at 12:59, wrote:
>>> Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
Perhaps there's room for further automation here, yet as with
any automation the question is ho
On Thu, 2015-10-08 at 12:36 +0100, Stefano Stabellini wrote:
> On Thu, 8 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
> >
> > > Furthermore, based on the spec (4.3.12 in IHI 0048B.b): "A register
> > > field corresponding to an unimplemented interrupt is
On Thu, 8 Oct 2015, Ian Campbell wrote:
> On Thu, 2015-10-08 at 12:36 +0100, Stefano Stabellini wrote:
> > On Thu, 8 Oct 2015, Ian Campbell wrote:
> > > On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
> > >
> > > > Furthermore, based on the spec (4.3.12 in IHI 0048B.b): "A register
> > > >
On 10/08/2015 02:22 PM, Jan Beulich wrote:
On 08.10.15 at 13:49, wrote:
On 10/08/2015 01:34 PM, Jan Beulich wrote:
On 08.10.15 at 12:59, wrote:
Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
Perhaps there's room for further automation here, yet as with
any automa
This run is configured for baseline tests only.
flight 38136 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38136/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 86cce64da95783fbc990934e75901cfadd768228
baseline version:
ovm
In fact, csched_vcpu_remove() (i.e., the credit1
implementation of remove_vcpu()) manipulates runqueues,
so holding the runqueue lock is necessary.
Also, while there, *_lock_irq() (for the private lock) is
enough, there is no need to *_lock_irqsave().
Signed-off-by: Dario Faggioli
---
Cc: George
Hi everyone,
This series originates from this other one:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03811.html
And, more specifically, from the review subthread of patch 3 (Jan's comments,
mainly):
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03812.html
http://lists.x
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, improve alignment of comments, ad
add a const qualifier to a pointer, making things
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.
For instance, in case of schedule_cpu_switch() the lock is
acquired in generic code. On the other hand, in case
rather than its hexadecimal representation. This makes
it easier to compare the actual system time with other
times being printed out (e.g., deadlines in RTDS).
Signed-off-by: Dario Faggioli
---
Cc: Juergen Gross
Cc: George Dunlap
---
xen/common/cpupool.c |2 +-
1 file changed, 1 insertion
Signed-off-by: Dario Faggioli
Reviewed-by: Juergen Gross
---
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 178a665..9213d98 100644
--- a/xen/common/sched_credi
Idle vCPUs should never really be explicitly inserted
in any of the schedulers' runqueue. In fact, they are
just put in execution immediately (either on boot, or
when a pCPU is assigned to a cpupool), and it will be
the first scheduling decision that --by preempting
them-- will 'park' them in the q
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Meng Xu
---
xen/common/sched_rt.c |
flight 38137 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38137/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-wheezy-netboot-pvgrub 10 guest-start fail REGR. vs. 38112
test-am
On Wed, 2015-10-07 at 16:07 +0100, Julien Grall wrote:
> On 06/10/15 15:55, Ian Campbell wrote:
> > On Tue, 2015-10-06 at 15:39 +0100, Julien Grall wrote:
> > > > > +csize = SZ_8K;
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Check if the CPU interface and virtual CPU in
On 08/10/15 13:53, Dario Faggioli wrote:
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 797adc1..0ca4902 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1147,7 +1147,7 @@ rt_dom_cntl(
> break;
> }
> spin_lock_irqsave(&prv
On 08/10/15 13:53, Dario Faggioli wrote:
> rather than its hexadecimal representation. This makes
> it easier to compare the actual system time with other
> times being printed out (e.g., deadlines in RTDS).
>
> Signed-off-by: Dario Faggioli
Reviewed-by: Andrew Cooper
There are a number of othe
On 08/10/15 13:52, Dario Faggioli wrote:
> In fact, csched_vcpu_remove() (i.e., the credit1
> implementation of remove_vcpu()) manipulates runqueues,
> so holding the runqueue lock is necessary.
>
> Also, while there, *_lock_irq() (for the private lock) is
> enough, there is no need to *_lock_irqsa
On Thu, 2015-10-08 at 14:10 +0100, Andrew Cooper wrote:
> On 08/10/15 13:53, Dario Faggioli wrote:
> > diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> > index 797adc1..0ca4902 100644
> > --- a/xen/common/sched_rt.c
> > +++ b/xen/common/sched_rt.c
> > @@ -1147,7 +1147,7 @@ rt_dom_cntl(
On 08/10/15 13:52, 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.
>
> For instance, in case of schedule_cpu_switch() the lock is
>
El 05/10/15 a les 12.28, Andrew Cooper ha escrit:
> On 02/10/15 16:48, Roger Pau Monne wrote:
>> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
>> VCPUOP_is_up hypercalls from HVM guests.
>>
>> This patch introduces a new structure (vcpu_hvm_context) that should be used
>> in
On 08/10/15 13:23, Ian Campbell wrote:
> On Thu, 2015-10-08 at 12:36 +0100, Stefano Stabellini wrote:
>> On Thu, 8 Oct 2015, Ian Campbell wrote:
>>> On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
>>>
Furthermore, based on the spec (4.3.12 in IHI 0048B.b): "A register
field corresp
On 08/10/15 13:52, Dario Faggioli wrote:
> @@ -319,14 +317,16 @@ rt_dump(const struct scheduler *ops)
> }
>
> printk("Domain info:\n");
> -list_for_each( iter_sdom, &prv->sdom )
> +list_for_each( iter, &prv->sdom )
> {
> -sdom = list_entry(iter_sdom, struct rt_dom,
Ian Campbell writes ("Re: [PATCH XEN v3 02/22] tools: Refactor "xentoollog"
into its own library"):
> In general this series doesn't really benefit from -M since only large
> chunks, but not entire files, are moving. This specific commit would
> benefit though and I've added -M to my script for ne
On Thu, Oct 08, 2015 at 02:39:40PM +0200, Juergen Gross wrote:
> On 10/08/2015 02:22 PM, Jan Beulich wrote:
> On 08.10.15 at 13:49, wrote:
> >>On 10/08/2015 01:34 PM, Jan Beulich wrote:
> >>On 08.10.15 at 12:59, wrote:
> Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release
On 08/10/15 13:53, Dario Faggioli wrote:
> @@ -1443,7 +1433,7 @@ csched2_dom_cntl(
>
> if ( op->u.credit2.weight != 0 )
> {
> -struct list_head *iter;
> +struct vcpu *vc;
Any chance of starting to align on the more common practice of just v
for a vcpu?
On Thu, 2015-10-08 at 14:53 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH QEMU-XEN-TRADITIONAL v3 1/5] qemu-xen
> -traditional: Use xentoollog as a separate library"):
> > I think when things are getting closer I will start preparing trees
> > which
> > could be pulled simultaneously
On 29/09/15 17:55, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
Acked-by: 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
>
Ian Campbell writes ("Re: [PATCH QEMU-XEN-TRADITIONAL v3 1/5]
qemu-xen-traditional: Use xentoollog as a separate library"):
> I think when things are getting closer I will start preparing trees which
> could be pulled simultaneously into all three and DTRT. We aren't close
> enough yet though.
An
On Thu, Oct 08, 2015 at 06:13:27AM -0600, Jan Beulich wrote:
> >>> On 08.10.15 at 13:10, wrote:
> > On Thu, Oct 08, 2015 at 02:05:51AM -0600, Jan Beulich wrote:
> >> Perhaps there's room for further automation here, yet as with
> >> any automation the question is how quickly getting this in place
On Thu, 2015-10-08 at 14:46 +0100, Julien Grall wrote:
> On 08/10/15 13:23, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 12:36 +0100, Stefano Stabellini wrote:
> > > On Thu, 8 Oct 2015, Ian Campbell wrote:
> > > > On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
> > > >
> > > > > Furthermor
On Thu, 2015-10-08 at 06:16 +0200, Juergen Gross wrote:
> [0] although we are still waiting for Konrad's reply on that one in
> > > the
> > > relevant thread.
> >
> > RIP PV superpages.
>
> Okay, I'll do this as soon as Roger's domain builder patches are
> committed.
I think the ones which might
On Fri, 2015-10-02 at 17:49 +0200, Roger Pau Monne wrote:
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index d6ef9a2..082fed8 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -98,6 +98,7 @@ libxl_device_model_version =
> Enumeration(
On Tue, 2015-10-06 at 11:24 -0400, Zhigang Wang wrote:
> We use these extentions along with xend XMLRPC API/xm. Even when move to
> xl, this will give us a choice to reserve some logic.
There are a lot of interfaces here, are you using all of them? If not then
could you enumerate the ones you care
On Tue, 2015-10-06 at 15:09 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 06, 2015 at 06:13:04PM +0100, Andrew Cooper wrote:
> > On 06/10/15 17:57, Wei Liu wrote:
> > > Various people say this binding doesn't compile or doesn't work.
> > > Remove
> > > it for the benefit of xl feature developme
Chunyan Liu writes ("[PATCH V7 3/7] libxl: add pvusb API"):
> Add pvusb APIs, including:
...
> +/* Utility to read backend xenstore keys */
> +#define READ_BACKEND(tgc, subpath)\
> +libxl__xs_read(tgc, XBT_NULL, GCSPRINTF("%s/" subpath, be_path))
> +
On Thu, 2015-10-08 at 15:41 +0100, Ian Jackson wrote:
> > +libxl_device_usbctrl *
> > +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num)
> > +{
>
> This function should return an rc, and the list should come in an out
> parameter.
For better of worse libxl.h defines the general
On 29/09/15 18:31, 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 case.
>>
>> In other w
On 10/08/2015 10:40 AM, Ian Campbell wrote:
> On Tue, 2015-10-06 at 15:09 -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Oct 06, 2015 at 06:13:04PM +0100, Andrew Cooper wrote:
>>> On 06/10/15 17:57, Wei Liu wrote:
Various people say this binding doesn't compile or doesn't work.
Remove
>>>
>>> On 08.10.15 at 16:23, wrote:
> On Thu, Oct 08, 2015 at 06:13:27AM -0600, Jan Beulich wrote:
>> >>> On 08.10.15 at 13:10, wrote:
>> > I fail to get the idea why this would be a problem. Maybe you're seeing
>> > every backport as your sole responsibility? From Xen project's point of
>> > view,
On 10/08/2015 10:38 AM, Ian Campbell wrote:
> On Tue, 2015-10-06 at 11:24 -0400, Zhigang Wang wrote:
>> We use these extentions along with xend XMLRPC API/xm. Even when move to
>> xl, this will give us a choice to reserve some logic.
>
> There are a lot of interfaces here, are you using all of the
On 08/10/15 13:52, 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.
>
> For instance, in case of schedule_cpu_switch() the lock is
Ian Campbell writes ("Re: [PATCH V7 3/7] libxl: add pvusb API"):
> Since this is part of a new "controller" abstraction we do in theory have
> the freedom to do things differently, but it seems to me that having
> something as basic as the list operation differ for devices vs. controller
> would do
On 08/10/15 15:58, George Dunlap wrote:
> On 29/09/15 18:31, 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
On Sat, 2015-10-03 at 02:39 +0200, Dario Faggioli wrote:
> There are some host related considerations. In fact, this test case
> requires
> that an host with at least 2 pCPUs is used. v2 was failing the test, if that
> was not the case. Now, I'm just skipping doing pretty much everything, but I'm
>
>>> On 08.10.15 at 15:35, wrote:
> El 05/10/15 a les 12.28, Andrew Cooper ha escrit:
>> On 02/10/15 16:48, Roger Pau Monne wrote:
>>> +#define SEG(b, l, a)\
>>> +(struct segment_register){ .sel = 0, .base = (b), .limit = (l), \
>>> +
The pv domain builder currently supports the additional flag
"superpages" to build a pv domain with 2MB pages. This feature isn't
being used by any component other than the python xc bindings.
Remove the flag and it's support from the xc bindings and the domain
builder
Signed-off-by: Juergen Gros
On 08/10/15 13:52, Dario Faggioli wrote:
> Idle vCPUs should never really be explicitly inserted
> in any of the schedulers' runqueue. In fact, they are
> just put in execution immediately (either on boot, or
> when a pCPU is assigned to a cpupool), and it will be
> the first scheduling decision th
On Thu, 2015-10-08 at 11:09 -0400, Zhigang Wang wrote:
> On 10/08/2015 10:38 AM, Ian Campbell wrote:
> > On Tue, 2015-10-06 at 11:24 -0400, Zhigang Wang wrote:
> > > We use these extentions along with xend XMLRPC API/xm. Even when move
> > > to
> > > xl, this will give us a choice to reserve some l
1 - 100 of 183 matches
Mail list logo
