On 2016/7/19 18:38, Wei Liu wrote:
> On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
> [...]
>>> > >
>>> > > It would be trivial to have another option in xl.cfg to allow MB
>>> > > granularity. But I don't think that's a good idea. Asking for more
>>> > > memory when you don't rea
flight 97644 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96211
test-amd64-i386-fr
On 20/07/16 07:10, SF Markus Elfring wrote:
> @@ -606,7 +606,7 @@ static void scsiback_device_action(struct
> vscsibk_pend *pending_req,
> tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
> if (!tmr) {
> target_put_sess_cmd(se_cmd);
> - goto err
@@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend
*pending_req,
tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
if (!tmr) {
target_put_sess_cmd(se_cmd);
- goto err;
+ goto do_resp;
}
>>>
On 19/07/16 16:56, SF Markus Elfring wrote:
>>> @@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend
>>> *pending_req,
>>> tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
>>> if (!tmr) {
>>> target_put_sess_cmd(se_cmd);
>>> - goto err;
>>
On 20/07/16 00:38, Stefano Stabellini wrote:
> On Fri, 15 Jul 2016, Paul Durrant wrote:
>>> -Original Message-
>>> From: Juergen Gross [mailto:jgr...@suse.com]
>>> Sent: 15 July 2016 12:37
>>> To: Stefano Stabellini; xen-de...@lists.xenproject.org
>>> Cc: joao.m.mart...@oracle.com; Wei Liu;
flight 97653 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97653/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
flight 97637 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96188
test-amd64-amd64-
Stefan Berger writes:
> Daniel Kiper wrote on 07/19/2016 11:00:04 AM:
>
>> Subject: Re: [PATCH] acpi: Re-license ACPI builder files from GPLv2
>> to LGPLv2.1
>>
>> On Mon, Jul 18, 2016 at 10:01:27AM -0400, Boris Ostrovsky wrote:
>> > ACPI builder is currently distributed under GPLv2 license.
This run is configured for baseline tests only.
flight 66616 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 11 guest-start
On Thu, 14 Jul 2016, Julien Grall wrote:
> It is not possible to know which IRQs will be used by DOM0 when ACPI is
> inuse. The approach implemented by this patch, will route all unused
> IRQs to DOM0 before it has booted.
>
> The number of IRQs routed is based on the maximum SPIs supported by the
On Thu, 14 Jul 2016, Julien Grall wrote:
> The comment was not correctly indented. Also the preferred name for the
> initial domain is "hardware domain" and not "dom0, so replace it.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - Patch adde
On Thu, 14 Jul 2016, Julien Grall wrote:
> The function route_irq_to_guest mandates the IRQ type, stored in
> desc->arch.type, to be valid. However, in case of ACPI, these
> information is not part of the static tables. Therefore Xen needs to
> rely on DOM0 to provide a valid type based on the firm
On Thu, 14 Jul 2016, Julien Grall wrote:
> A follow-up patch will not store the type in desc->arch.type. Also, the
> callback prototype is more logical.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - gic_set_irq_type has been dropped by m
On Thu, 14 Jul 2016, Julien Grall wrote:
> The affinity of a guest IRQ is set every time the guest enable it (see
> vgic_enable_irqs).
>
> It is not necessary to set the affinity when the IRQ is routed to the
> guest because Xen will never receive the IRQ until it hass been enabled
> by the guest.
On Fri, 15 Jul 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Juergen Gross [mailto:jgr...@suse.com]
> > Sent: 15 July 2016 12:37
> > To: Stefano Stabellini; xen-de...@lists.xenproject.org
> > Cc: joao.m.mart...@oracle.com; Wei Liu; Roger Pau Monne; Lars Kurth;
> > boris.ostrov.
On 07/19/2016 04:58 AM, Roger Pau Monne wrote:
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index d8530f0..fd80442 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -4742,7 +4742,7 @@ static void migrate_domain(uint32_t domid, const char
> *rune,
On Monday 18 July 2016 15:57:09 Andrew Cooper wrote:
> On 18/07/16 15:30, Mihai Donțu wrote:
> > @@ -4409,6 +4409,10 @@ x86_emulate(
> > case 0x6f: /* movq mm/m64,mm */
> > /* {,v}movdq{a,u} xmm/m128,xmm */
> > /* vmovdq{a,u} ymm/m256,ymm */
> > +case 0x7e:
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-debianhvm-amd64
testid debian-hvm-install
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xen
Daniel Kiper wrote on 07/19/2016 11:00:04 AM:
> Subject: Re: [PATCH] acpi: Re-license ACPI builder files from GPLv2
> to LGPLv2.1
>
> On Mon, Jul 18, 2016 at 10:01:27AM -0400, Boris Ostrovsky wrote:
> > ACPI builder is currently distributed under GPLv2 license.
> >
> > We plan to make the build
On Tue, Jul 19, 2016 at 11:11 AM, George Dunlap
wrote:
> On 18/07/16 18:06, Tamas K Lengyel wrote:
>>> Incremental improvements are welcome; but they must not cause
>>> regressions in existing functionality.
>>
>> Existing functionality does not get impaired by this as what happens
>> right now is
flight 97638 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97638/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
flight 97661 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97661/
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 dump_guest_s1_walk function was incorrectly using the top 10 bits of
the virtual address to select the L1 page table index. The correct
amount is 12 bits, resulting in a shift of 20 bits rather than 22.
For more details, see the ARMv7-A ARM, section B3.5, "Short-descriptor
translation table f
dump_guest_s1_walk intends to walk to level 2 page table entries but
was failing to do so because of a check that caused level 2 page table
descriptors to be ignored. This change fixes the check so that level 2
page table walks occur as intended by ignoring descriptors unless their
low two bits mat
On 18/07/16 18:06, Tamas K Lengyel wrote:
>> Incremental improvements are welcome; but they must not cause
>> regressions in existing functionality.
>
> Existing functionality does not get impaired by this as what happens
> right now is a hypervisor crash. I don't see how things can get any
> wors
flight 97627 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 96791
test-amd64-amd64-li
On Tue, Jul 19, 2016 at 10:55 AM, Andrew Cooper
wrote:
> On 19/07/16 17:54, Tamas K Lengyel wrote:
>> On Tue, Jul 19, 2016 at 10:49 AM, Andrew Cooper
>> wrote:
>>> On 19/07/16 17:27, Tamas K Lengyel wrote:
>> +{
>> +int rc = 0;
>> +shr_handle_t sh, ch;
>> +unsigned lon
On 19/07/16 17:54, Tamas K Lengyel wrote:
> On Tue, Jul 19, 2016 at 10:49 AM, Andrew Cooper
> wrote:
>> On 19/07/16 17:27, Tamas K Lengyel wrote:
> +{
> +int rc = 0;
> +shr_handle_t sh, ch;
> +unsigned long start =
> +range->_scratchspace ? range->_scratchsp
On Tue, Jul 19, 2016 at 10:49 AM, Andrew Cooper
wrote:
> On 19/07/16 17:27, Tamas K Lengyel wrote:
>>
+{
+int rc = 0;
+shr_handle_t sh, ch;
+unsigned long start =
+range->_scratchspace ? range->_scratchspace : range->start;
>>> This can be shortened to
On 19/07/16 17:27, Tamas K Lengyel wrote:
>
>>> +{
>>> +int rc = 0;
>>> +shr_handle_t sh, ch;
>>> +unsigned long start =
>>> +range->_scratchspace ? range->_scratchspace : range->start;
>> This can be shortened to "unsigned long start = range->_scratchspace ?:
>> range->start;"
On Tue, Jul 19, 2016 at 1:54 AM, Julien Grall wrote:
> Hello Tamas,
>
> On 18/07/2016 22:14, Tamas K Lengyel wrote:
>>
>> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
>> index e904bd5..0ca94cd 100644
>> --- a/tools/libxc/include/xenctrl.h
>> +++ b/tools/libxc/include/
On Mon, Jul 18, 2016 at 3:47 PM, Andrew Cooper
wrote:
> On 18/07/2016 22:14, Tamas K Lengyel wrote:
>> Currently mem-sharing can be performed on a page-by-page basis from the
>> control
>> domain. However, this process is quite wasteful when a range of pages have to
>> be deduplicated.
>>
>> This
On Tue, Jul 19, 2016 at 10:06:57AM -0600, Tamas K Lengyel wrote:
> On Tue, Jul 19, 2016 at 7:48 AM, Wei Liu wrote:
> > This email only tracks big items for xen.git tree. Please reply for items
> > you
> > woulk like to see in 4.8 so that people have an idea what is going on and
> > prioritise acc
On Tue, Jul 19, 2016 at 7:48 AM, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the featu
On Tue, Jul 19, 2016 at 05:50:32PM +0200, Roger Pau Monne wrote:
> On Tue, Jul 19, 2016 at 02:15:28PM +0100, Wei Liu wrote:
> > On Tue, Jul 19, 2016 at 10:58:15AM +0200, Roger Pau Monne wrote:
> > > This is useful for debugging domains that crash on resume from migration.
> > >
> > > Signed-off-by
On Tue, Jul 19, 2016 at 02:15:28PM +0100, Wei Liu wrote:
> On Tue, Jul 19, 2016 at 10:58:15AM +0200, Roger Pau Monne wrote:
> > This is useful for debugging domains that crash on resume from migration.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: ian.jack...@eu.citrix.com
> > Cc: wei.l.
In fact, when not finding a suitable runqueue where to
place a vCPU, and hence using a fallback, we either:
- don't issue any trace record (while we should),
- risk underruning when accessing the runqueues
array, while preparing the trace record.
Fix both issues and, while there, also a coupl
both introduced in d205f8a7f48e2ec ("xen: credit2: rework
load tracking logic").
First, in __update_runq_load(), the ASSERT() was actually
useless. Let's instead check that the computed value of
the load has not overflowed (and hence gone negative).
While there, do that in __update_svc_load() as
v2 of <146892985892.30642.2392453881110942183.st...@solace.fritz.box>, as v1
was making things worse!
In fact, there was a bug in patch 1 which turned the ASSERT() from being
useless to being wrong, and it was actually triggering.
Sorry for the noise.
Regards,
Dario
---
Dario Faggioli (2):
On Tue, Jul 19, 2016 at 7:36 AM, Ian Jackson wrote:
> Tamas: George brought this thread to my attention. I'm sorry that you
> feel blocked and/or overruled. The hypervisor MM code is not my area
> of expertise, but I have a keen interest in seeing a good, productive
> and friendly Xen community.
On 07/19/2016 11:21 AM, anshul makkar wrote:
On 19/07/16 14:30, Doug Goldstein wrote:
On 7/19/16 4:05 AM, Anshul Makkar wrote:
Signed-off-by: Anshul Makkar
---
* Resending the patch due to incomplete subject in the previous patch.
docs/misc/xsm-flask.txt | 8
1 file changed, 4 i
On 19/07/16 14:30, Doug Goldstein wrote:
On 7/19/16 4:05 AM, Anshul Makkar wrote:
Signed-off-by: Anshul Makkar
---
* Resending the patch due to incomplete subject in the previous patch.
docs/misc/xsm-flask.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/
On Tue, Jul 19, 2016 at 5:39 AM, George Dunlap wrote:
> On 18/07/16 18:06, Tamas K Lengyel wrote:
Anyhow, at this point I'm
going to start carrying out-of-tree patches for Xen in my project and
just resign from my mem_sharing maintainership as I feel like it's
pretty pointless.
flight 97623 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97623/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 97562
build-i386-rumpuserxen
On Mon, Jul 18, 2016 at 10:01:27AM -0400, Boris Ostrovsky wrote:
> ACPI builder is currently distributed under GPLv2 license.
>
> We plan to make the builder available to components other
> than the hvmloader (which is also GPLv2). Some of these
> components (such as libxl) may be distributed under
>> @@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend
>> *pending_req,
>> tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
>> if (!tmr) {
>> target_put_sess_cmd(se_cmd);
>> -goto err;
>> +goto do_resp;
>> }
>
> Hmm
On 07/19/2016 05:11 AM, Jan Beulich wrote:
Boris Ostrovsky 07/08/16 6:20 PM >>>
>> On 07/08/2016 11:35 AM, Jan Beulich wrote:
>> On 08.07.16 at 17:23, wrote:
Is it up to the builder to decide which tables are important and which
are not?
>>> I'm afraid that's not so easy to tel
This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.8 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
Tamas: George brought this thread to my attention. I'm sorry that you
feel blocked and/or overruled. The hypervisor MM code is not my area
of expertise, but I have a keen interest in seeing a good, productive
and friendly Xen community. I definitely don't want to see you pushed
away, and driven
On Tue, 2016-07-19 at 14:07 +0200, Dario Faggioli wrote:
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -656,7 +656,8 @@ __update_runq_load(const struct scheduler *ops,
> rqd->load += change;
> rqd->load_last_update = now;
>
> -ASSERT(rqd->avgload <= STIM
On 7/19/16 4:05 AM, Anshul Makkar wrote:
> Signed-off-by: Anshul Makkar
> ---
> * Resending the patch due to incomplete subject in the previous patch.
>
> docs/misc/xsm-flask.txt | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
> ---
> diff --git a/docs/misc/xsm-flask.txt b/docs/
On Mon, Jul 18, 2016 at 04:31:30PM +0100, Wei Liu wrote:
> On Sat, Jul 16, 2016 at 01:47:56AM +0200, Marek Marczykowski-Górecki wrote:
> > When this daemon is started after creating backend device, that device
> > will not be configured.
> >
> > Racy situation:
> > 1. driver domain is started
> >
Queued. Thanks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Jul 19, 2016 at 02:08:18PM +0200, Juergen Gross wrote:
> Add support for debugging memory allocation statistics to xenstored.
> Specifying "-M " on the command line will enable the feature.
> Whenever xenstored receives SIGUSR1 it will dump out a full talloc
> report to . This helps finding
On Tue, Jul 19, 2016 at 10:58:15AM +0200, Roger Pau Monne wrote:
> This is useful for debugging domains that crash on resume from migration.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: ian.jack...@eu.citrix.com
> Cc: wei.l...@citrix.com
> ---
> Changes since v1:
> - Document the newly added o
On 19/07/16 13:26, Dario Faggioli wrote:
> On Tue, 2016-07-19 at 13:20 +0100, Andrew Cooper wrote:
>> On 19/07/16 13:06, Dario Faggioli wrote:
>>> Series committed yesterday, to be precise, and two (not too big, at
>>> least :-))
>>> issues, have been found already (thanks Andrew!).
>> I tend to pu
On Tue, 2016-07-19 at 13:20 +0100, Andrew Cooper wrote:
> On 19/07/16 13:06, Dario Faggioli wrote:
> >
> > Series committed yesterday, to be precise, and two (not too big, at
> > least :-))
> > issues, have been found already (thanks Andrew!).
> I tend to put "Spotted by Coverity." in the commit m
On 19/07/16 13:06, Dario Faggioli wrote:
> Series committed yesterday, to be precise, and two (not too big, at least :-))
> issues, have been found already (thanks Andrew!).
I tend to put "Spotted by Coverity." in the commit message of these,
even when we can't provide CID numbers.
Its not like I
Add support for debugging memory allocation statistics to xenstored.
Specifying "-M " on the command line will enable the feature.
Whenever xenstored receives SIGUSR1 it will dump out a full talloc
report to . This helps finding e.g. memory leaks in xenstored.
Signed-off-by: Juergen Gross
---
To
In fact, when not finding a suitable runqueue where to
place a vCPU, and hence using a fallback, we either:
- don't issue any trace record (while we should),
- risk underruning when accessing the runqueues
array, while preparing the trace record.
Fix both issues and, while there, also a coupl
both introduced in d205f8a7f48e2ec ("xen: credit2: rework
load tracking logic").
First, in __update_runq_load(), the ASSERT() was actually
useless. Let's instead check that the computed value of
the load has not overflowed (and hence gone negative).
While there, do that in __update_svc_load() as
Series committed yesterday, to be precise, and two (not too big, at least :-))
issues, have been found already (thanks Andrew!).
Thanks and Regards,
Dario
---
Dario Faggioli (2):
xen: credit2: fix two s_time_t handling issues in load balancing
xen: credit2: fix potential issues in csch
On Fri, Jul 15, 2016 at 07:28:26AM +0200, Juergen Gross wrote:
> Add support for debugging memory allocation statistics to xenstored.
> Specifying "-M " on the command line will enable the feature.
> Whenever xenstored receives SIGUSR1 it will dump out a full talloc
> report to . This helps finding
On 18/07/16 18:06, Tamas K Lengyel wrote:
>>> Anyhow, at this point I'm
>>> going to start carrying out-of-tree patches for Xen in my project and
>>> just resign from my mem_sharing maintainership as I feel like it's
>>> pretty pointless.
>>
>> I'm sorry that you're discouraged; all I can say is th
xenstored has a memory leak when setting watches: a no longer active
watch which fired in the past will still use some memory. This is
critical for long running connections to xenstored like the qemu
process serving as a qdisk backend for dom0. It will use some few
kB in xenstored for each domain c
Use a temporary memory context for memory allocations when firing
watches. This will avoid leaking memory in case of long living
connections and/or xenstore entries.
This requires adding a new parameter to fire_watches() and add_event()
to specify the memory context to use for allocations.
Signed
In order to be able to avoid leaving temporary memory allocated after
processing of a command in xenstored call all command functions with
the temporary "in" context. Each function can then make use of that
temporary context for allocating temporary memory instead of either
leaving that memory allo
Add a parameter to xenstored read_node() function to explicitly
specify the memory context to be used for allocations. This will make
it easier to avoid memory leaks by using a context which is freed
soon.
When calling read_node() select a sensible memory context for the new
parameter by preferrin
Add a parameter to xenstored get_parent() function to explicitly
specify the memory context to be used for allocations. This will make
it easier to avoid memory leaks by using a context which is freed
soon.
When available use a temporary context when calling get_parent(),
otherwise mimic the old b
Add a parameter to xenstored get_node() function to explicitly
specify the memory context to be used for allocations. This will make
it easier to avoid memory leaks by using a context which is freed
soon.
This requires adding the temporary context to errno_from_parents() and
ask_parents(), too.
W
On 07/15/2016 06:55 PM, Anthony PERARD wrote:
On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote:
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq_
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a
configuration option for ARM DomU ACPI"):
...
> > >>> I know but here we want to unify the acpi option for x86 and ARM while
> > >>> on x86 it's true by default. What I want to ask is that how to
> > >>> distinguish x86
Wei Liu writes ("Re: [PATCH v2 5/5] xenstore: use temporary memory context for
firing watches"):
> On Mon, Jul 18, 2016 at 09:31:29AM +0200, Juergen Gross wrote:
> > static void add_event(struct connection *conn,
> > + void *tmp,
>
> tmp -> ctx or context.
Once again,
Acked-by:
On Mon, Jul 18, 2016 at 12:40:43PM -0700, Stefano Stabellini wrote:
[...]
> > #if defined(__arm__) || defined(__aarch64__)
> > ?
>
> I am not a Libxl maintainer anymore, but I think that should be OK or at
> least it would be a step in the right direction.
Yes, I think that's the correct ifdefs t
Wei Liu writes ("Re: [PATCH v2 4/5] xenstore: add explicit memory context
parameter to get_node()"):
> On Mon, Jul 18, 2016 at 09:31:28AM +0200, Juergen Gross wrote:
> > Add a parameter to xenstored get_node() function to explicitly
> > specify the memory context to be used for allocations. This w
On Fri, Jul 15, 2016 at 05:39:32PM +0800, Shannon Zhao wrote:
[...]
> >
> > It would be trivial to have another option in xl.cfg to allow MB
> > granularity. But I don't think that's a good idea. Asking for more
> > memory when you don't really know how much is enough is not very useful.
> > If an
Wei Liu writes ("Re: [PATCH v2 3/5] xenstore: add explicit memory context
parameter to read_node()"):
> On Mon, Jul 18, 2016 at 09:31:27AM +0200, Juergen Gross wrote:
> > /* If it fails, returns NULL and sets errno. */
> > -static struct node *read_node(struct connection *conn, const char *name)
Juergen Gross writes ("[PATCH v2 2/5] xenstore: add explicit memory context
parameter to get_parent()"):
> Add a parameter to xenstored get_parent() function to explicitly
> specify the memory context to be used for allocations. This will make
> it easier to avoid memory leaks by using a context w
Wei Liu writes ("Re: [PATCH v2 2/5] xenstore: add explicit memory context
parameter to get_parent()"):
> I would name mem ctx or context instead. And maybe document this
> function a bit saying that memory allocation is done with the first
> parameter.
>
> With those cosmetic issues fixed:
>
> R
Juergen Gross writes ("[PATCH v2 1/5] xenstore: call each xenstored command
function with temporary context"):
> In order to be able to avoid leaving temporary memory allocated after
> processing of a command in xenstored call all command functions with
> the temporary "in" context. Each function
On Mon, Jul 18, 2016 at 09:31:29AM +0200, Juergen Gross wrote:
> static void add_event(struct connection *conn,
> + void *tmp,
tmp -> ctx or context.
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
On Tue, 2016-07-19 at 11:05 +0100, George Dunlap wrote:
> On 19/07/16 10:57, Dario Faggioli wrote:
> >
> > > What about folding in something like the attached patch?
> > >
> > I'd be totally fine with this.
> Do you mean you ack me folding in that particular patch (so that the
> resulting commit
On 07/15/2016 07:11 PM, Anthony PERARD wrote:
On Fri, Jul 15, 2016 at 12:15:45PM +0100, Wei Liu wrote:
On Fri, Jul 15, 2016 at 12:28:48PM +0200, Paulina Szubarczyk wrote:
On 07/14/2016 12:37 PM, Wei Liu wrote:
On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote:
diff --git
On 07/19/2016 11:12 AM, Roger Pau Monné wrote:
On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote:
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq
On 19/07/16 10:57, Dario Faggioli wrote:
> On Tue, 2016-07-19 at 10:39 +0100, George Dunlap wrote:
>> On Mon, Jul 18, 2016 at 6:24 PM, Dario Faggioli
>> wrote:
>>>
>>> If you're saying that this discrepancy between rqd->idle's and
>>> rqd->smt_idle's semantic is, at minimum, unideal, I do agree.
On Mon, Jul 18, 2016 at 09:31:28AM +0200, Juergen Gross wrote:
> Add a parameter to xenstored get_node() function to explicitly
> specify the memory context to be used for allocations. This will make
> it easier to avoid memory leaks by using a context which is freed
> soon.
>
> This requires addi
On Mon, Jul 18, 2016 at 09:31:26AM +0200, Juergen Gross wrote:
> Add a parameter to xenstored get_parent() function to explicitly
> specify the memory context to be used for allocations. This will make
> it easier to avoid memory leaks by using a context which is freed
> soon.
>
> When available u
On Mon, Jul 18, 2016 at 09:31:27AM +0200, Juergen Gross wrote:
> Add a parameter to xenstored read_node() function to explicitly
> specify the memory context to be used for allocations. This will make
> it easier to avoid memory leaks by using a context which is freed
> soon.
>
> When calling read
On Mon, Jul 18, 2016 at 09:31:25AM +0200, Juergen Gross wrote:
> In order to be able to avoid leaving temporary memory allocated after
> processing of a command in xenstored call all command functions with
> the temporary "in" context. Each function can then make use of that
> temporary context for
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/li
On Tue, 2016-07-19 at 10:39 +0100, George Dunlap wrote:
> On Mon, Jul 18, 2016 at 6:24 PM, Dario Faggioli
> wrote:
> >
> > If you're saying that this discrepancy between rqd->idle's and
> > rqd->smt_idle's semantic is, at minimum, unideal, I do agree... but
> > I
> > think, for now at least, it's
On Mon, Jul 18, 2016 at 6:24 PM, Dario Faggioli
wrote:
> On Mon, 2016-07-18 at 17:48 +0100, George Dunlap wrote:
>> On 15/07/16 15:50, Dario Faggioli wrote:
>> >
>> > +/*
>> > + * If all the siblings of cpu (including cpu itself) are in
>> > idlers,
>> > + * set all their bits in mask.
>> > + *
>>
On 7/18/2016 9:07 PM, Andrew Cooper wrote:
On 15/07/16 08:18, Corneliu ZUZU wrote:
On 7/12/2016 9:10 AM, Corneliu ZUZU wrote:
On 7/11/2016 7:43 PM, Tamas K Lengyel wrote:
On Sat, Jul 9, 2016 at 12:46 PM, Corneliu ZUZU
wrote:
On 7/9/2016 9:10 PM, Tamas K Lengyel wrote:
On Fri, Jul 8, 2016 at
On Tue 19-07-16 10:35:09, Sebastian Gottschall wrote:
> No such Message-ID known.
Ups, sorry about that. I didn't know that the stable tree is not
archived via lkml.kernel.org. Here is the link
http://www.spinics.net/lists/stable/msg138760.html
> Am 19.07.2016 um 10:32 schrieb Michal Hocko:
> >
On Mon, Jul 18, 2016 at 06:49:33PM +0100, Andrew Cooper wrote:
> On 18/07/16 17:15, Anthony PERARD wrote:
> > It as been modified by:
> > 3c8d890 x86/PVHv2: update the start info structure layout
> > 247d38c xen: change the sizes of memory fields in the HVM start info to be
> > 64bits
> >
> > Sign
On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
>
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operati
>>> Boris Ostrovsky 07/08/16 6:20 PM >>>
>On 07/08/2016 11:35 AM, Jan Beulich wrote:
> On 08.07.16 at 17:23, wrote:
>>> Is it up to the builder to decide which tables are important and which
>>> are not?
>> I'm afraid that's not so easy to tell. If for example we can't fit the
>> HPET table,
flight 97622 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
1 - 100 of 122 matches
Mail list logo
