If the domain is already where we want it to go,
there's not much to do indeed.
Signed-off-by: Dario Faggioli
---
Cc: Juergen Gross
---
xen/common/cpupool.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index 5dacc61..9998394 100644
--- a/
Hi,
Small cpupool couple of patches.
One is a small optimization, while the other fixes a nasty --although currently
only theoretical-- bug in the domain destruction path.
Regards, Dario
---
Dario Faggioli (2):
xen: fix a (latent) cpupool-related race during domain destroy
xen: cpupo
So, during domain destruction, we do:
cpupool_rm_domain()[ in domain_destroy() ]
sched_destroy_domain() [ in complete_domain_destroy() ]
Therefore, there's a window during which, from the
scheduler's point of view, a domain is still there, but
without it being part of any cpupool.
In fact,
On 13.07.2016 23:03, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-13 11:56:30)
On 13.07.2016 20:43, Stefano Stabellini wrote:
On Wed, 13 Jul 2016, Dirk Behme wrote:
On 13.07.2016 00:26, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-12 00:46:45)
Clocks described by this propert
On 13.07.2016 21:07, Stefano Stabellini wrote:
On Wed, 13 Jul 2016, Dirk Behme wrote:
On 13.07.2016 20:35, Stefano Stabellini wrote:
On Tue, 12 Jul 2016, Dirk Behme wrote:
Clocks described by this property are reserved for use by Xen, and the OS
must not alter their state any way, such as disa
On 7/13/2016 10:12 PM, Julien Grall wrote:
Hi Corneliu,
On 13/07/2016 15:18, Corneliu ZUZU wrote:
Move duplicate macros between asm-arm/arm32/atomic.h and
asm-arm/arm64/atomic.h
to asm-arm/atomic.h.
asm-arm/arm*/atomic.h were a copy from Linux. I don't mind if we
diverge, however the file x
flight 97278 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 96188
test-amd64-amd64-xl-qe
On 14/07/16 02:18, Paul Gortmaker wrote:
> Historically a lot of these existed because we did not have
> a distinction between what was modular code and what was providing
> support to modules via EXPORT_SYMBOL and friends. That changed
> when we forked out support for the latter into the export.h
This is a mostly-mechanical conversion that creates a new flat
union 'Netdev' QAPI type that covers all the branches of the
former 'NetClientOptions' simple union, where the branches are
now listed in a new 'NetClientDriver' enum rather than generated
from the simple union. The existence of a flat
flight 97275 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97275/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 96993
build-amd64-rumpuserxen
The only user verify_local_APIC() had been removed by
commit 4399c03c6780 ("x86/apic: Remove verify_local_APIC()"),
so no need to keep it.
Signed-off-by: Wei Jiangang
---
arch/x86/include/asm/apic.h | 1 -
arch/x86/kernel/apic/apic_flat_64.c | 2 --
arch/x86/kernel/apic/apic_noop.c
flight 97272 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97272/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 96767
test-amd64-amd64-xl-qemuu-win7-amd
Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends. That changed
when we forked out support for the latter into the export.h file.
This means we should be able to reduce th
Originally module.h provided support for both what was modular code and
what was providing support to modules via EXPORT_SYMBOL and friends.
That changed when we forked out support for the latter into the export.h
header; roughly five years ago[1].
We dealt with the immediate fallout of that chan
flight 97271 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97271/
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
flight 97273 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97273/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 94748
test-amd64-i386-
On 07/13/2016 05:06 PM, Andrew Cooper wrote:
> On 13/07/2016 21:57, Boris Ostrovsky wrote:
>> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
>>> On 13/07/2016 21:17, Boris Ostrovsky wrote:
On 07/13/2016 04:02 PM, Andrew Cooper wrote:
> On 13/07/16 20:44, Boris Ostrovsky wrote:
>> I would
On 13/07/2016 21:57, Boris Ostrovsky wrote:
> On 07/13/2016 04:34 PM, Andrew Cooper wrote:
>> On 13/07/2016 21:17, Boris Ostrovsky wrote:
>>> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
On 13/07/16 20:44, Boris Ostrovsky wrote:
> I would like to clear a bunch of Xen heap pages at once (i.
Quoting Dirk Behme (2016-07-13 11:56:30)
> On 13.07.2016 20:43, Stefano Stabellini wrote:
> > On Wed, 13 Jul 2016, Dirk Behme wrote:
> >> On 13.07.2016 00:26, Michael Turquette wrote:
> >>> Quoting Dirk Behme (2016-07-12 00:46:45)
> Clocks described by this property are reserved for use by Xen
On 07/13/2016 04:34 PM, Andrew Cooper wrote:
> On 13/07/2016 21:17, Boris Ostrovsky wrote:
>> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>>> On 13/07/16 20:44, Boris Ostrovsky wrote:
I would like to clear a bunch of Xen heap pages at once (i.e. not
page-by-page).
Greatly simpl
On 13/07/2016 21:17, Boris Ostrovsky wrote:
> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>> On 13/07/16 20:44, Boris Ostrovsky wrote:
>>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>>> page-by-page).
>>>
>>> Greatly simplifying things, let's say I grab (in common/page_alloc
flight 97276 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97276/
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
On 07/13/2016 04:17 PM, Boris Ostrovsky wrote:
> On 07/13/2016 04:02 PM, Andrew Cooper wrote:
>> On 13/07/16 20:44, Boris Ostrovsky wrote:
>>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>>> page-by-page).
>>>
>>> Greatly simplifying things, let's say I grab (in common/page_al
On 7/13/2016 10:49 PM, Andrew Cooper wrote:
On 13/07/16 20:33, Corneliu ZUZU wrote:
On 7/13/2016 10:01 PM, Stefano Stabellini wrote:
On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
Create a common-side to establish, among others,
prototypes of
atomic functions called from common-code. Done to avoid
On 07/13/2016 04:02 PM, Andrew Cooper wrote:
> On 13/07/16 20:44, Boris Ostrovsky wrote:
>> I would like to clear a bunch of Xen heap pages at once (i.e. not
>> page-by-page).
>>
>> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
>> pg = page_list_remove_head(&heap(node, z
When we build Xen with the Rules.mk modified we end up:
ld -mi386pep --subsystem=10 --image-base=0x82d08000 --stack=0,0
--heap=0,0 --strip-debug --section-alignment=0x20 --file-alignment=0x20
--major-image-version=4 --minor-image-version=8 --major-os-version=2
--minor-os-version=0 -
On 13/07/16 20:44, Boris Ostrovsky wrote:
> I would like to clear a bunch of Xen heap pages at once (i.e. not
> page-by-page).
>
> Greatly simplifying things, let's say I grab (in common/page_alloc.c)
> pg = page_list_remove_head(&heap(node, zone, order)
>
> and then
>
> mfn_t mfn =
> _mfn(
On 13/07/16 20:33, Corneliu ZUZU wrote:
> On 7/13/2016 10:01 PM, Stefano Stabellini wrote:
>> On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
>>> Create a common-side to establish, among others,
>>> prototypes of
>>> atomic functions called from common-code. Done to avoid introducing
>>> inconsistencies
I would like to clear a bunch of Xen heap pages at once (i.e. not
page-by-page).
Greatly simplifying things, let's say I grab (in common/page_alloc.c)
pg = page_list_remove_head(&heap(node, zone, order)
and then
mfn_t mfn =
_mfn(page_to_mfn(pg));
Hi Julien,
On 7/13/2016 10:12 PM, Julien Grall wrote:
Hi Corneliu,
On 13/07/2016 15:18, Corneliu ZUZU wrote:
Move duplicate macros between asm-arm/arm32/atomic.h and
asm-arm/arm64/atomic.h
to asm-arm/atomic.h.
asm-arm/arm*/atomic.h were a copy from Linux. I don't mind if we
diverge, howeve
On 7/13/2016 10:01 PM, Stefano Stabellini wrote:
On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
Create a common-side to establish, among others, prototypes of
atomic functions called from common-code. Done to avoid introducing
inconsistencies between arch-side headers when we make subtle
changes to
Hi Corneliu,
On 13/07/2016 15:18, Corneliu ZUZU wrote:
Move duplicate macros between asm-arm/arm32/atomic.h and asm-arm/arm64/atomic.h
to asm-arm/atomic.h.
asm-arm/arm*/atomic.h were a copy from Linux. I don't mind if we
diverge, however the file xen/arch/arm/README.primitives needs to be
up
On Wed, 13 Jul 2016, Dirk Behme wrote:
> On 13.07.2016 20:35, Stefano Stabellini wrote:
> > On Tue, 12 Jul 2016, Dirk Behme wrote:
> > > Clocks described by this property are reserved for use by Xen, and the OS
> > > must not alter their state any way, such as disabling or gating a clock,
> > > or
On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> Create a common-side to establish, among others, prototypes of
> atomic functions called from common-code. Done to avoid introducing
> inconsistencies between arch-side headers when we make subtle
> changes to one of them.
>
> Some arm-side macros had
On 13.07.2016 20:43, Stefano Stabellini wrote:
On Wed, 13 Jul 2016, Dirk Behme wrote:
On 13.07.2016 00:26, Michael Turquette wrote:
Quoting Dirk Behme (2016-07-12 00:46:45)
Clocks described by this property are reserved for use by Xen, and the OS
must not alter their state any way, such as dis
On Tue, Jul 12, 2016 at 10:26 PM, Corneliu ZUZU wrote:
> On 7/9/2016 9:57 PM, Corneliu ZUZU wrote:
>>
>> On 7/9/2016 9:26 PM, Tamas K Lengyel wrote:
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index ae1dcb4..7663da2 100644
--- a/xen/include/asm-x86/
On 07/13/2016 03:56 AM, Wei, Jiangang wrote:
> On Thu, 2016-07-07 at 11:37 -0400, Boris Ostrovsky wrote:
>> On 07/07/2016 11:25 AM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 07, 2016 at 11:28:18AM +0800, Wei Jiangang wrote:
verify_local_APIC() had been removed by
commit 4399c03c6780 ("
On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> This wouldn't let me make a param of a function that used atomic_read() const.
>
> Signed-off-by: Corneliu ZUZU
> Reviewed-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> Changed since v1:
> ---
> xen/include/asm-arm/atomic.h | 2 +-
> x
On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> Reorder macro definitions to match x86-side.
>
> Signed-off-by: Corneliu ZUZU
Reviewed-by: Stefano Stabellini
> xen/include/asm-arm/atomic.h | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/xen/include/
On Wed, 13 Jul 2016, Corneliu ZUZU wrote:
> Place atomic_inc_and_test() implementation after atomic_inc().
> Also remove unneeded empty line and add a needed one.
>
> Signed-off-by: Corneliu ZUZU
For the ARM bit, even though it is a bit embarassing acking a one-liner
empty line addition:
Acked-
On 13.07.2016 20:35, Stefano Stabellini wrote:
On Tue, 12 Jul 2016, Dirk Behme wrote:
Clocks described by this property are reserved for use by Xen, and the OS
must not alter their state any way, such as disabling or gating a clock,
or modifying its rate. Ensuring this may impose constraints on
On Wed, 13 Jul 2016, Dirk Behme wrote:
> On 13.07.2016 00:26, Michael Turquette wrote:
> > Quoting Dirk Behme (2016-07-12 00:46:45)
> > > Clocks described by this property are reserved for use by Xen, and the OS
> > > must not alter their state any way, such as disabling or gating a clock,
> > > or
On Tue, 12 Jul 2016, Dirk Behme wrote:
> Clocks described by this property are reserved for use by Xen, and the OS
> must not alter their state any way, such as disabling or gating a clock,
> or modifying its rate. Ensuring this may impose constraints on parent
> clocks or other resources used by t
On Wed, 13 Jul 2016, Anna-Maria Gleixner wrote:
> From: Richard Cochran
>
> Install the callbacks via the state machine and let the core invoke
> the callbacks on the already online CPUs.
>
> The get_cpu() in xen_starting_cpu() boils down to preempt_disable() since
> we already know the CPU we r
On 07/13/2016 10:30 AM, Lars Kurth wrote:
>
> On 13/07/2016 15:22, "Boris Ostrovsky" wrote:
>
>> On 07/13/2016 09:21 AM, Lars Kurth wrote:
>>> Boris,
>>>
>>> I can't remember how we managed this process the last time round (see
>>> for https://patchwork.kernel.org/patch/9172431/), but in that case
On Tue, 12 Jul 2016, Julien Grall wrote:
> More the half of the arguments of INSERT and REMOVE are the same for
> each callers. Simplify the callers of apply_p2m_changes by adding new
> helpers which will fill common arguments with default values.
>
> Signed-off-by: Julien Grall
Acked-by: Stefan
On Tue, 12 Jul 2016, Julien Grall wrote:
> Most of the callers of apply_p2m_changes have a GFN, a MFN and the
> number of frame to change in hand.
>
> Rather than asking each caller to convert the frame to an address,
> rework the interfaces to pass the GFN, MFN and the number of frame.
>
> Note
On Tue, 12 Jul 2016, Julien Grall wrote:
> to avoid mixing machine frame with guest frame. Also drop the prefix start_.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v6:
> - Qualify what is being mapped
> - Use PRI_mfn
>
> Changes in
On Tue, 12 Jul 2016, Julien Grall wrote:
> The parameter 'access' is used by memaccess to restrict temporarily the
> permission. This parameter should not be used for other purpose (such
> as restricting permanently the permission).
>
> Instead, we should use the default access requested by memace
On 07/13/2016 08:59 AM, Anshul Makkar wrote:
Access to setpodtarget is required by dom0 to set the balloon targets for
domU. The patch gives source domain (dom0) access to set this target for
domU and resolve the following permission denied error message during
ballooning :
avc: denied { setpod
On Wed, 13 Jul 2016, Andrew Cooper wrote:
> On 13/07/16 16:47, Stefano Stabellini wrote:
> > Hi all,
> >
> > This is the design document of the XenSock protocol. You can find
> > prototypes of the Linux frontend and backend drivers here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/sstabel
From: Richard Cochran
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
The get_cpu() in xen_starting_cpu() boils down to preempt_disable() since
we already know the CPU we run on. Disabling preemption shouldn't be required
here from wh
On 07/13/2016 11:22 AM, Julien Grall wrote:
> Hello,
>
> On 12/07/2016 17:58, Boris Ostrovsky wrote:
>> On 07/12/2016 12:10 PM, Julien Grall wrote:
>>> On 12/07/2016 16:08, Boris Ostrovsky wrote:
On 07/12/2016 10:57 AM, Shannon Zhao wrote:
> On 2016年07月12日 22:50, Wei Liu wrote:
>> On T
flight 97274 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97274/
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
On 13/07/16 16:47, Stefano Stabellini wrote:
> Hi all,
>
> This is the design document of the XenSock protocol. You can find
> prototypes of the Linux frontend and backend drivers here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xensock-2
>
> To use them, make sure to ena
Hi all,
This is the design document of the XenSock protocol. You can find
prototypes of the Linux frontend and backend drivers here:
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git xensock-2
To use them, make sure to enable CONFIG_XENSOCK in your kernel config
and add "xensock=
On 10/07/16 16:44, Michael Young wrote:
> On Wed, 29 Jun 2016, Michael Young wrote:
>
>> I have been trying to trace a problem when using Fedora's qemu with a
>> pv guest which is that no graphics are available. I get the errors
>>
>> xen be core: xen be: watching backend path (backend/console/2) f
Hello,
On 12/07/2016 17:58, Boris Ostrovsky wrote:
On 07/12/2016 12:10 PM, Julien Grall wrote:
On 12/07/2016 16:08, Boris Ostrovsky wrote:
On 07/12/2016 10:57 AM, Shannon Zhao wrote:
On 2016年07月12日 22:50, Wei Liu wrote:
On Tue, Jul 12, 2016 at 10:42:07PM +0800, Shannon Zhao wrote:
Does it m
At 14:46 +0100 on 13 Jul (1468421211), Andrew Cooper wrote:
> On 22/06/16 14:12, Tim Deegan wrote:
> > At 12:24 +0100 on 22 Jun (1466598248), Andrew Cooper wrote:
> >> The C standard defines two types of conforming implementation; hosted and
> >> freestanding. A subset of the standard headers are
On Wed, Jul 13, 2016 at 10:53:13AM +0200, Roger Pau Monne wrote:
> This is useful for debugging domains that crash on resume from migration.
>
> Signed-off-by: Roger Pau Monné
This sounds like a useful thing to have and the patch looks good.
But you forgot to patch xl(1) manpage.
Wei.
___
On 13/07/16 16:28, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] xenstored memory leak"):
>> On 13/07/16 14:32, Juergen Gross wrote:
>>> On 13/07/16 15:17, David Vrabel wrote:
The Linux driver already cleans up open transactions and removes watches
when the file handle is rel
flight 97269 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-build fail REGR. vs. 96794
Tests which di
On 13/07/2016 15:22, "Boris Ostrovsky" wrote:
>On 07/13/2016 09:21 AM, Lars Kurth wrote:
>> Boris,
>>
>> I can't remember how we managed this process the last time round (see
>>for https://patchwork.kernel.org/patch/9172431/), but in that case we
>>already had a patch. As far as I can see, we d
David Vrabel writes ("Re: [Xen-devel] xenstored memory leak"):
> On 13/07/16 14:32, Juergen Gross wrote:
> > On 13/07/16 15:17, David Vrabel wrote:
> >> The Linux driver already cleans up open transactions and removes watches
> >> when the file handle is released.
> >
> > Hmm, does this work relia
Create a common-side to establish, among others, prototypes of
atomic functions called from common-code. Done to avoid introducing
inconsistencies between arch-side headers when we make subtle
changes to one of them.
Some arm-side macros had to be turned into inline functions in the process.
Rem
This wouldn't let me make a param of a function that used atomic_read() const.
Signed-off-by: Corneliu ZUZU
Reviewed-by: Andrew Cooper
---
Changed since v1:
---
xen/include/asm-arm/atomic.h | 2 +-
xen/include/asm-x86/atomic.h | 2 +-
xen/include/xen/atomic.h | 2 +-
3 files changed, 3 in
On 07/13/2016 09:21 AM, Lars Kurth wrote:
> Boris,
>
> I can't remember how we managed this process the last time round (see for
> https://patchwork.kernel.org/patch/9172431/), but in that case we already had
> a patch. As far as I can see, we don't have the complete patch yet.
>
> Thus, the ques
Reorder macro definitions to match x86-side.
Signed-off-by: Corneliu ZUZU
---
xen/include/asm-arm/atomic.h | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
index 19a87a5..e8f7340 100644
--- a/xen/
Place atomic_inc_and_test() implementation after atomic_inc().
Also remove unneeded empty line and add a needed one.
Signed-off-by: Corneliu ZUZU
---
xen/include/asm-arm/atomic.h | 1 +
xen/include/asm-x86/atomic.h | 39 +++
2 files changed, 20 insertions(+),
Move duplicate macros between asm-arm/arm32/atomic.h and asm-arm/arm64/atomic.h
to asm-arm/atomic.h.
Signed-off-by: Corneliu ZUZU
---
xen/include/asm-arm/arm32/atomic.h | 11 ---
xen/include/asm-arm/arm64/atomic.h | 11 ---
xen/include/asm-arm/atomic.h | 11 +++
3 f
On Wed, Jul 13, 2016 at 04:09:26PM +0200, Juergen Gross wrote:
> On 13/07/16 15:52, Wei Liu wrote:
> > On Wed, Jul 13, 2016 at 03:25:45PM +0200, Juergen Gross wrote:
> >> On 13/07/16 15:07, Wei Liu wrote:
> >>> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> On 06/07/16 09:31,
Corneliu ZUZU (5):
asm-arm/atomic.h: fix arm32|arm64 macros duplication
asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement
asm-arm/atomic.h: reorder macros to match x86-side
asm/atomic.h: common prototyping (add xen/atomic.h)
fix: make atomic_read() param const
xen/include/
On Tue, Jul 12, 2016 at 04:21:00PM +, Rusty Bird wrote:
> Hello Wei,
>
> For systemd/xendriverdomain.service.in, the hardcoded PID file could be
> removed altogether -- systemd has no trouble figuring out the PID with
> only one process. But I wasn't sure if maybe something outside of the
> xe
On 13/07/16 15:52, Wei Liu wrote:
> On Wed, Jul 13, 2016 at 03:25:45PM +0200, Juergen Gross wrote:
>> On 13/07/16 15:07, Wei Liu wrote:
>>> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
On 06/07/16 09:31, Juergen Gross wrote:
> While testing some patches for support of bal
On Wed, Jul 13, 2016 at 03:25:45PM +0200, Juergen Gross wrote:
> On 13/07/16 15:07, Wei Liu wrote:
> > On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> >> On 06/07/16 09:31, Juergen Gross wrote:
> >>> While testing some patches for support of ballooning in Mini-OS by using
> >>> the
On 13/07/16 15:17, David Vrabel wrote:
> On 13/07/16 14:07, Wei Liu wrote:
>>
>> My gut feeling is that xenstored shouldn't have the knowledge to
>> associate a watch with a "process". The concept of a process is only
>> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
>> Mayb
On Wed, Jul 13, 2016 at 02:20:28PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] xenstored memory leak"):
> > On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> > > qemu as the device model is setting up a xenstore watch for each backend
> > > type it is supporting. Unf
On 22/06/16 14:12, Tim Deegan wrote:
> At 12:24 +0100 on 22 Jun (1466598248), Andrew Cooper wrote:
>> The C standard defines two types of conforming implementation; hosted and
>> freestanding. A subset of the standard headers are the freestanding headers,
>> requiring no library support at all to
On 13/07/16 14:32, Juergen Gross wrote:
> On 13/07/16 15:17, David Vrabel wrote:
>> On 13/07/16 14:07, Wei Liu wrote:
>>>
>>> My gut feeling is that xenstored shouldn't have the knowledge to
>>> associate a watch with a "process". The concept of a process is only
>>> meaningful to OS, which wouldn'
Juergen Gross writes ("Re: [Xen-devel] xenstored memory leak"):
> On 13/07/16 14:40, Andrew Cooper wrote:
> > On 13/07/16 13:21, Juergen Gross wrote:
> >> I'll post a qemu patch to remove those watches on exit soon.
I don't think this is right. qemu should not explictly remove watches
when it is
On 12/07/16 17:28, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 12, 2016 at 7:44 AM, Vitaly Kuznetsov wrote:
>> PVHVM guests may need to know Xen's idea of vCPU ids they have and the
>> only way they can figure them out is to use ACPI ids from MADT table.
>> Document the de facto policy.
>>
>> Signe
On 12/07/16 19:13, Tamas K Lengyel wrote:
> This patch implements sending notification to a monitor subscriber when an
> x86/vmx guest executes the CPUID instruction.
>
> Signed-off-by: Tamas K Lengyel
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
> Cc: Razvan Cojocaru
> Cc: Jan Beulich
> Cc: Andrew C
On 13/07/16 15:07, Wei Liu wrote:
> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
>> On 06/07/16 09:31, Juergen Gross wrote:
>>> While testing some patches for support of ballooning in Mini-OS by using
>>> the xenstore domain I realized that each xl create/destroy pair would
>>> in
Wei Liu writes ("[PATCH] libxl: constify src parameter of
libxl_nocpuid.c:libxl_cpuid_policy_list_copy"):
> In 11316d31 ("libxl: constify copy and length calculation functions") I
> forgot to take care of libxl_nocpuid.c which also contains an
> implementation of libxl_cpuid_policy_list_copy. That
Boris,
I can't remember how we managed this process the last time round (see for
https://patchwork.kernel.org/patch/9172431/), but in that case we already had a
patch. As far as I can see, we don't have the complete patch yet.
Thus, the question I would have to you is whether you want to prepar
On 13/07/16 14:20, Corneliu ZUZU wrote:
> On 7/13/2016 3:12 PM, Andrew Cooper wrote:
>> On 13/07/16 12:23, Corneliu ZUZU wrote:
>>> +typedef struct { int counter; } atomic_t;
>>> +
>>> +#define ATOMIC_INIT(i) { (i) }
>>> +
>>> +/**
>>> + * atomic_read - read atomic variable
>>> + * @v: pointer of t
In 11316d31 ("libxl: constify copy and length calculation functions") I
forgot to take care of libxl_nocpuid.c which also contains an
implementation of libxl_cpuid_policy_list_copy. That broke ARM build.
Fix it by constifying the src parameter.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
I've c
On 13/07/16 14:40, Andrew Cooper wrote:
> On 13/07/16 13:21, Juergen Gross wrote:
>> On 06/07/16 09:31, Juergen Gross wrote:
>>> While testing some patches for support of ballooning in Mini-OS by using
>>> the xenstore domain I realized that each xl create/destroy pair would
>>> increase memory con
Wei Liu writes ("Re: [Xen-devel] xenstored memory leak"):
> On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> > qemu as the device model is setting up a xenstore watch for each backend
> > type it is supporting. Unfortunately those watches are never removed
> > again. This sums up to
On 7/13/2016 3:12 PM, Andrew Cooper wrote:
On 13/07/16 12:23, Corneliu ZUZU wrote:
+typedef struct { int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+/**
+ * atomic_read - read atomic variable
+ * @v: pointer of type atomic_t
+ *
+ * Atomically reads the value of @v.
+ */
+static in
On 13/07/16 14:07, Wei Liu wrote:
>
> My gut feeling is that xenstored shouldn't have the knowledge to
> associate a watch with a "process". The concept of a process is only
> meaningful to OS, which wouldn't work on cross-domain xenstored setup.
> Maybe the OS xenbus driver should reap all watche
flight 97263 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/97263/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate running
test-a
On 12/07/16 14:59, Julien Grall wrote:
> Hello all,
>
> Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.
>
> To avoid more confusion, this patch series makes use of the terminology
> described in xen/include/xen/mm.h and the associated typesafe.
>
> I pushed a branch with
flight 97265 seabios running [real]
http://logs.test-lab.xenproject.org/osstest/logs/97265/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 2 hosts-allocate running
t
On Wed, Jul 13, 2016 at 01:55:26PM +0100, Ian Jackson wrote:
> osstest service owner writes ("[xen-unstable-smoke test] 97261: regressions -
> FAIL"):
> > flight 97261 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/97261/
> >
> > Regressions :-(
> >
> > Tests
On Wed, Jul 13, 2016 at 02:21:38PM +0200, Juergen Gross wrote:
> On 06/07/16 09:31, Juergen Gross wrote:
> > While testing some patches for support of ballooning in Mini-OS by using
> > the xenstore domain I realized that each xl create/destroy pair would
> > increase memory consumption in Mini-OS
flight 97264 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/97264/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt queued
test-armhf-armhf-libv
On Wed, 13 Jul 2016 05:52:33 -0700
Josh Triplett wrote:
> On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
> > return 0;
> > }
> >
> > +int kexec_cr
Access to setpodtarget is required by dom0 to set the balloon targets for
domU. The patch gives source domain (dom0) access to set this target for
domU and resolve the following permission denied error message during
ballooning :
avc: denied { setpodtarget } for domid=0 target=9
scontext=system_u
osstest service owner writes ("[xen-unstable-smoke test] 97261: regressions -
FAIL"):
> flight 97261 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/97261/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
1 - 100 of 146 matches
Mail list logo
