-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Thu, 16 Feb 2017 08:58:01 +0100
schrieb Juergen Gross :
> You can't assume ./configure is running on the same system as Xen is
> being built for.
I think its easy to decide at build time if the target has and/or uses
"/run". And this will not chang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Thu, 16 Feb 2017 08:58:01 +0100
schrieb Juergen Gross :
> You can't assume ./configure is running on the same system as Xen is
> being built for.
I think its easy to decide at build time if the target has and/or uses
"/run". And this will not chang
On Wed, 2017-02-15 at 08:15 -0700, Jan Beulich wrote:
> > > > On 15.02.17 at 15:55, wrote:
> >
> > On Wed, 2017-02-15 at 06:20 -0700, Jan Beulich wrote:
> > > > > > On 15.02.17 at 11:27, wrote:
> > > >
> > > > This is what I'm getting during the original test case (32 VMs reboot):
> > > >
> >
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I will define 2 sections:
*-- Connector Request Transport Parameters
---
*
* ctrl-event-channel
* ctrl-ring-ref
*
*--- Connector Event Transport Parameters
---
Hi Andrew,
On 15/02/2017 18:10, Andrew Cooper wrote:
This file is included automatically via CFLAGS.
Signed-off-by: Andrew Cooper
For the ARM bits:
Acked-by: Julien Grall
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.
Hi Andrew,
On 15/02/2017 18:10, Andrew Cooper wrote:
xen/config.h includes asm/config.h, and is included automatically via CFLAGS.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@
Hi Andrew,
On 15/02/2017 18:10, Andrew Cooper wrote:
generated/autoconf.h is already included automatically so CONFIG_* defines are
avaialble. However, the companion macros such as IS_ENABLED() are not
NIT: s/avaialble/available/
included.
Include them uniformally everywhere.
Signed-off-b
Paul,
as it looks to be quite non-trivial an operation, did you happen to
have to backport commit 480b83162a to 4.4 or older, without
backporting all the ioreq server stuff at the same time? It looks to
me as if the issue predates the addition of ioreq servers, and us
having had customer reports h
>>> On 16.02.17 at 09:29, wrote:
> On Wed, 2017-02-15 at 08:15 -0700, Jan Beulich wrote:
>> > > > On 15.02.17 at 15:55, wrote:
>> > Is it worth giving your patch another try with removing ctxt_switch_same()
>> > since we figured out that vmx_do_resume() will reload vmcs either way?
>>
>> Yes, bu
On Thu, 16 Feb 2017, Juergen Gross wrote:
> On 16/02/17 08:52, Olaf Hering wrote:
> > Am Wed, 15 Feb 2017 15:51:12 -0500
> > schrieb Konrad Rzeszutek Wilk :
> >> mkdir /run/xen
> >> mkdir /run/xenstored
> >
> > This must be done by the startup scripts because the "run" directories,
> > where ever
>>> On 15.02.17 at 22:53, wrote:
> On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote:
>> >>> On 14.02.17 at 19:38, wrote:
>> > --- a/xen/arch/x86/boot/head.S
>> > +++ b/xen/arch/x86/boot/head.S
>> > @@ -394,10 +394,18 @@ __start:
>> >
>> > /* EFI IA-32 platforms are not support
>>> On 15.02.17 at 20:30, wrote:
> On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote:
> On 15.02.17 at 00:21, wrote:
>>> On 14/02/2017 22:47, Tamas K Lengyel wrote:
(XEN) Switched to APIC driver x2apic_cluster.
(XEN) XSM Framework v1.0.0 initialized
(XEN) Flask: 128 avtab has
Hi Stefano,
On 15/02/2017 23:05, Stefano Stabellini wrote:
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. Increase it to 512M.
Signed-off-by: Stefano Stabellini
I am not a big fan of increasing the default value. 128M is plenty
enough if you use a small DO
>>> On 15.02.17 at 18:43, wrote:
> 1.
> I need:
> Allow P2M core on ARM to update IOMMU mapping from the first "p2m_set_entry".
> I do:
> I explicitly set need_iommu flag for *every* guest domain during
> iommu_domain_init() on ARM in case if page table is not shared.
> At that moment I have no kn
>>> On 15.02.17 at 23:34, wrote:
> From: Lv Zheng
>
> ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca
>
> This patch adds support for IORT (IO Remapping Table) in iasl.
>
> Note that some field names are modified to shrink their length or the
> decompiled IORT ASL will contain fields wi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 February 2017 09:21
> To: Paul Durrant
> Cc: xen-devel
> Subject: backport of "x86/hvm: don't rely on shared ioreq state for
> completion handling" ?
>
> Paul,
>
> as it looks to be quite non-trivial an opera
>>> On 16.02.17 at 11:13, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 February 2017 09:21
>>
>> as it looks to be quite non-trivial an operation, did you happen to
>> have to backport commit 480b83162a to 4.4 or older, without
>> backporting all the ioreq server stuff at th
>>> On 15.02.17 at 18:39, wrote:
> Extend the Maptrack comment to point at the Grant table subsystem.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://l
>>> On 15.02.17 at 18:39, wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 15.02.17 at 19:10, wrote:
> This file is included automatically via CFLAGS.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 15.02.17 at 19:10, wrote:
> generated/autoconf.h is already included automatically so CONFIG_* defines are
> avaialble. However, the companion macros such as IS_ENABLED() are not
> included.
>
> Include them uniformally everywhere.
Well, if you really think this is a good idea, I'm not g
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 February 2017 10:23
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for
> completion handling" ?
>
> >>> On 16.02.17 at 11:13, wrote:
> >> From: Jan Be
>>> On 15.02.17 at 20:41, wrote:
> The now-common hcall_preempted boolean is perfectly usable for multicalls.
Something must have gone in the wrong order here: This is not part
of a series, and I can't see hcall_preempted being common in
staging.
Jan
___
On 16/02/17 10:27, Jan Beulich wrote:
On 15.02.17 at 19:10, wrote:
>> generated/autoconf.h is already included automatically so CONFIG_* defines
>> are
>> avaialble. However, the companion macros such as IS_ENABLED() are not
>> included.
>>
>> Include them uniformally everywhere.
> Well, if
On 16/02/17 10:37, Jan Beulich wrote:
On 15.02.17 at 20:41, wrote:
>> The now-common hcall_preempted boolean is perfectly usable for multicalls.
> Something must have gone in the wrong order here: This is not part
> of a series, and I can't see hcall_preempted being common in
> staging.
Sorr
>>> On 15.02.17 at 20:41, wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -202,6 +202,8 @@ struct vcpu
> bool paused_for_shutdown;
> /* VCPU need affinity restored */
> bool affinity_broken;
> +/* A hypercall has been preempted
>>> On 16.02.17 at 11:36, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 February 2017 10:23
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for
>> completion handling" ?
>>
>> >>> On
>>> On 16.02.17 at 11:40, wrote:
> On 16/02/17 10:27, Jan Beulich wrote:
> On 15.02.17 at 19:10, wrote:
>>> generated/autoconf.h is already included automatically so CONFIG_* defines
>>> are
>>> avaialble. However, the companion macros such as IS_ENABLED() are not
>>> included.
>>>
>>> Incl
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 February 2017 10:46
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for
> completion handling" ?
>
> >>> On 16.02.17 at 11:36, wrote:
> >> -Origin
flight 105824 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105824/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-xl
>>> On 16.02.17 at 11:53, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 February 2017 10:46
>> To: Paul Durrant
>> Cc: xen-devel
>> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for
>> completion handling" ?
>>
>> >>> On
On 16/02/17 10:48, Jan Beulich wrote:
On 16.02.17 at 11:40, wrote:
>> On 16/02/17 10:27, Jan Beulich wrote:
>> On 15.02.17 at 19:10, wrote:
generated/autoconf.h is already included automatically so CONFIG_* defines
are
avaialble. However, the companion macros such as IS_
>>> On 15.02.17 at 20:41, wrote:
> The now-common hcall_preempted boolean is perfectly usable for multicalls.
> Remove the multicall-specific preemption mechanism.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing lis
>>> On 15.02.17 at 20:41, wrote:
> HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of
> the hypercall in use.
>
> The rest of Xen deals in terms of the comat ABI or not, so rename the boolean
> and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI
>>> On 16.02.17 at 12:01, wrote:
> On 16/02/17 10:48, Jan Beulich wrote:
> On 16.02.17 at 11:40, wrote:
>>> On 16/02/17 10:27, Jan Beulich wrote:
>>> On 15.02.17 at 19:10, wrote:
> generated/autoconf.h is already included automatically so CONFIG_*
> defines
> are
> avaialbl
1: VMX: fix VMCS race on context-switch paths
2: x86: package up context switch hook pointers
Signed-off-by: Jan Beulich
---
v2: Several changes to patch 1 (see there) requiring adjustment to
patch 2 (again, see there).
___
Xen-devel mailing list
X
>>> On 15.02.17 at 12:21, wrote:
> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote:
>> >>> On 14.02.17 at 18:33, wrote:
>> >> TBD: Do we really want to re-init the TSS every time we are about to
>> >> use it?
>> >
>> > No - I think we should init it when the guest writes the param(
When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At t
They're all solely dependent on guest type, so we don't need to repeat
all the same three pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and expand
schedule_ta
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 February 2017 11:00
> To: Paul Durrant
> Cc: xen-devel
> Subject: RE: backport of "x86/hvm: don't rely on shared ioreq state for
> completion handling" ?
>
> >>> On 16.02.17 at 11:53, wrote:
> >> -Origin
2016-11-11 04:49, Tan, Jianfeng:
> Hi Thomas and Konrad,
>
> On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote:
> >> 2016-11-07 07:38, Jianfeng Tan:
> >>> As some users are still using xen as the hypervisor, I suggest to
> >>> continue su
>>> On 15.02.17 at 20:41, wrote:
> --- a/xen/arch/x86/hypercall.c
> +++ b/xen/arch/x86/pv/hypercall.c
> @@ -1,5 +1,7 @@
> /**
> - * arch/x86/hypercall.c
> + * arch/pv/hypercall.c
arch/x86/pv/hypercall.c (if we really need
>>> On 16.02.17 at 12:17, wrote:
> Roger's repro was with FreeBSD which is quite PV aware AFAIK. All my prior
> testing was done with Windows. So, maybe this points at a problem with
> libxl's behaviour when a guest is shutting down?
Not impossible, but with what you say I will want to be even
>>> On 15.02.17 at 20:41, wrote:
> The newly-repurposed arch/x86/hypercall.c is a more appropriate place for the
> hypercall continuation logic to live.
>
> This is purely code motion.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xe
On 16/02/17 11:16, Jan Beulich wrote:
> They're all solely dependent on guest type, so we don't need to repeat
> all the same three pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it an
>>> On 16.02.17 at 12:14, wrote:
On 15.02.17 at 12:21, wrote:
>> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote:
>>> >>> On 14.02.17 at 18:33, wrote:
>>> >> TBD: Do we really want to re-init the TSS every time we are about to
>>> >> use it?
>>> >
>>> > No - I think we should
flight 105827 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
104590
Tests whi
On 16/02/17 11:10, Jan Beulich wrote:
On 16.02.17 at 12:01, wrote:
>> On 16/02/17 10:48, Jan Beulich wrote:
>> On 16.02.17 at 11:40, wrote:
On 16/02/17 10:27, Jan Beulich wrote:
On 15.02.17 at 19:10, wrote:
>> generated/autoconf.h is already included automatically so C
Hi Jan,
On 16/02/17 11:10, Jan Beulich wrote:
On 16.02.17 at 12:01, wrote:
On 16/02/17 10:48, Jan Beulich wrote:
On 16.02.17 at 11:40, wrote:
On 16/02/17 10:27, Jan Beulich wrote:
On 15.02.17 at 19:10, wrote:
generated/autoconf.h is already included automatically so CONFIG_* defines
are
From: Andrii Anisov
The rangeset_domain_initialise() does nothing rangeset specific.
Even keeping it specific to domain looks not reasonable. So drop it.
Signed-off-by: Andrii Anisov
---
xen/common/domain.c| 3 ++-
xen/common/rangeset.c | 7 ---
xen/include/xen/rangeset.h | 4
From: Andrii Anisov
rangeset_new is made domain agnostic. The domain specific code
is moved to common/domain.c:domain_rangeset_new().
It is still left a rangesets list functionality: rangeset_new() is
returning its list head if requested. This would be reconsidered
further.
Signed-off-by: Andri
From: Andrii Anisov
rangeset_destroy is made domain agnostic. The domain specific code
is moved to common/domain.c:domain_rangeset_destroy().
It is still left a rangesets list functionality: rangeset_destroy()
will remove itself from a list. If a spinlock is provided it will be
held for list del
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/rangeset.c | 3 +--
xen/include/xen/rangeset.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index c18fb21..857615b 100644
--- a/xen/common/rangeset.c
+++ b/
From: Andrii Anisov
Rangesets in XEN seems to be a pretty generic thing slightly poisoned with.
domain specific funtionality in initialization and deinitialization code.
So make the rangeset code generic with moving domain specific code to
common/domain.c
Andrii Anisov (6):
rangeset_new() ref
From: Andrii Anisov
rangeset_domain_destroy() is rather rangeset list helper and does nothing really
domain specific. So replace it with rangeset_list_destroy() helper.
Signed-off-by: Andrii Anisov
---
xen/common/domain.c| 4 ++--
xen/common/rangeset.c | 11 ---
xen/inclu
From: Andrii Anisov
rangeset_domain_printk() is split into generic rangeset_list_printk() function
and domain specific common/domain.c:domain_rangeset_printk().
Signed-off-by: Andrii Anisov
---
xen/common/domain.c| 14 ++
xen/common/keyhandler.c| 2 +-
xen/common/range
Hi Andrew,
On 15/02/17 19:41, Andrew Cooper wrote:
With hcall_preempted having just been made common, ARM can use use it to
simplify its hypercall handling.
This simplifies the continuation logic and removes the risk of accidentally
skipping multiple instructions.
Signed-off-by: Andrew Cooper
Hi Andrew,
On 15/02/17 19:41, Andrew Cooper wrote:
The now-common hcall_preempted boolean is perfectly usable for multicalls.
Remove the multicall-specific preemption mechanism.
Signed-off-by: Andrew Cooper
For the ARM bits:
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:03
> To: xen-de...@lists.xenproject.org
> Cc: andrii_ani...@epam.com; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> ; sstab
On Fri, 2017-02-10 at 10:32 -0800, Stefano Stabellini wrote:
> On Fri, 10 Feb 2017, Dario Faggioli wrote:
> > Right, interesting use case. I'm glad to see there's some interest
> > in
> > it, and am happy to help investigating, and trying to make things
> > better.
>
> Thank you!
>
Hey, FYI, I am
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:03
> To: xen-de...@lists.xenproject.org
> Cc: andrii_ani...@epam.com; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> ; sstab
On 16/02/17 11:15, Jan Beulich wrote:
> When __context_switch() is being bypassed during original context
> switch handling, the vCPU "owning" the VMCS partially loses control of
> it: It will appear non-running to remote CPUs, and hence their attempt
> to pause the owning vCPU will have no effect
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:03
> To: xen-de...@lists.xenproject.org
> Cc: andrii_ani...@epam.com; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
> ; sstab
>>> On 16.02.17 at 13:27, wrote:
> On 16/02/17 11:15, Jan Beulich wrote:
>> When __context_switch() is being bypassed during original context
>> switch handling, the vCPU "owning" the VMCS partially loses control of
>> it: It will appear non-running to remote CPUs, and hence their attempt
>> to pa
>>> On 16.02.17 at 12:59, wrote:
> On 16/02/17 11:10, Jan Beulich wrote:
> On 16.02.17 at 12:01, wrote:
>>> On 16/02/17 10:48, Jan Beulich wrote:
>>> On 16.02.17 at 11:40, wrote:
> On 16/02/17 10:27, Jan Beulich wrote:
> On 15.02.17 at 19:10, wrote:
>>> generated/autocon
Dear Paul,
> The cleanup seems a good thing to do to me.
So I would collect comments, rebase it to latest master and push the
second version without RFC.
> Any particular reason this series is RFC?
The reason to make this series was an intention to use rangesets to
manage mmio ranges in our sha
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 12:46
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; sstabel
On Wed, Feb 15, 2017 at 12:11:12PM +0100, Juergen Gross wrote:
> Specifying an empty cdrom device will result in a Xenstore entry
>
> params = aio:(null)
>
> as the physical device path isn't existing. This lets a domain booted
> via OVMF hang as OVMF is checking for "aio:" only in order to detec
Both patches applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Dear Paul,
> Many moons ago there were patches to use rbtree for rangesets. Perhaps it
> would be worth reviving that idea?
rbtree is a thing I think of now for our needs.
Even more, currently I think of refactoring ARM mmio ranges managing
to use rbtree one day. Currently there is a static array
>> +if ( d != NULL )
>
> Shouldn't d == NULL be a hard error now, in which you could pass d->rangesets
> directly into rangeset_new() (under lock).
It definitely should. Because this is a domain specific code.
Sincerely,
Andrii Anisov.
___
Xen-dev
flight 105831 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105831/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105685
test-armhf-armhf-libvirt
Paul,
> Many moons ago there were patches to use rbtree for rangesets. Perhaps it
> would be worth reviving that idea?
Do you have a link to look at those patches?
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://li
>>> On 16.02.17 at 13:45, wrote:
> Dear Paul,
>
>> The cleanup seems a good thing to do to me.
>
> So I would collect comments, rebase it to latest master and push the
> second version without RFC.
>
>> Any particular reason this series is RFC?
>
> The reason to make this series was an intenti
On Thu, Feb 16, 2017 at 12:06:18PM +0100, Thomas Monjalon wrote:
> 2016-11-11 04:49, Tan, Jianfeng:
> > Hi Thomas and Konrad,
> >
> > On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote:
> > >> 2016-11-07 07:38, Jianfeng Tan:
> > >>> As s
Dear Jan,
> If this is meant to be per-domain management - how many such
> ranges do you expect to be necessary for any one domain? We've
> had attempts before to (ab)use rangesets for such a purpose.
It is meant to be the per-domain management. To handle per-domain
vcoproc register access emulati
Dear Jan,
I'm really sorry, but I did not get your point here:
> This concern makes me assume there might be quite many of them,
> which then makes this a no-go for unprivileged domains.
Could you please provide wider explanation.
Sincerely,
Andrii Anisov.
_
Le 16/02/2017 à 12:06, Thomas Monjalon a écrit :
The request (6 month ago) was to give more time for feedbacks:
http://dpdk.org/ml/archives/dev/2016-July/044847.html
Is it time now to officially remove Dom0 support?
yes
___
Xen-devel mailing
On 02/16/2017 02:47 AM, Juergen Gross wrote:
There have been reports that Fedora 25 uses /run instead of /var/run.
Add a --with-rundir option ito configure to be able to specify that
directory. Default is still /var/run.
As discussed on the other thread, why not make default be the location
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 13:24
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; sstabel
On 16/02/17 13:52, Boris Ostrovsky wrote:
>
>
> On 02/16/2017 02:47 AM, Juergen Gross wrote:
>> There have been reports that Fedora 25 uses /run instead of /var/run.
>>
>> Add a --with-rundir option ito configure to be able to specify that
>> directory. Default is still /var/run.
>
> As discussed o
On 16/02/17 14:52, Boris Ostrovsky wrote:
>
>
> On 02/16/2017 02:47 AM, Juergen Gross wrote:
>> There have been reports that Fedora 25 uses /run instead of /var/run.
>>
>> Add a --with-rundir option ito configure to be able to specify that
>> directory. Default is still /var/run.
>
> As discusse
Dear Paul,
>> It is still left a rangesets list functionality: rangeset_destroy()
>> will remove itself from a list. If a spinlock is provided it will be
>> held for list deletion operation. This would be reconsidered further.
>>
>
> Maybe use the same scheme in patch #1 then and pass the lock, as
flight 68566 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68566/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
> The relevant patch is:
>
> https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html
Thank you for the link.
I would try to realize why it is left unmerged.
Sincerely,
Andrii Anisov.
2017-02-16 16:02 GMT+02:00 Paul Durrant :
>> -Original Message-
>> From: Andrii Aniso
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 16 February 2017 14:26
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ;
> jbeul...@suse.com; konrad.w...@oracle.com; sstabel
>>> On 16.02.17 at 14:42, wrote:
> I'm really sorry, but I did not get your point here:
>
>> This concern makes me assume there might be quite many of them,
>> which then makes this a no-go for unprivileged domains.
>
> Could you please provide wider explanation.
Well, as it had been discussed
Hi,
On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote:
Hi Konrad,
Thanks for the feedback.
On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk
wrote:
On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote:
As per "VM S
On 16/02/17 15:12, Andrew Cooper wrote:
> On 16/02/17 13:52, Boris Ostrovsky wrote:
>>
>>
>> On 02/16/2017 02:47 AM, Juergen Gross wrote:
>>> There have been reports that Fedora 25 uses /run instead of /var/run.
>>>
>>> Add a --with-rundir option ito configure to be able to specify that
>>> directo
>>> On 15.02.17 at 20:41, wrote:
> Making PV and HVM guests individually compilable is useful as a reduction in
> hypervisor size, and as an aid to enforcing clean API boundaries.
>
> Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do
> until either can actually be disabled
Hi,
On 14/02/17 17:42, Wei Liu wrote:
(test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | grep
arndale
arndale-bluewater XenDTUARTPath /serial@12C2
arndale-lakeside XenDTUARTPath /serial@12C2
arndale-metrocentre XenDTUARTPat
On 16/02/17 14:39, Jan Beulich wrote:
On 15.02.17 at 20:41, wrote:
>> Making PV and HVM guests individually compilable is useful as a reduction in
>> hypervisor size, and as an aid to enforcing clean API boundaries.
>>
>> Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to
flight 105837 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105837/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fd12acdeff7a04ad34ccb95103eb6204b8901749
baseline version:
ovmf cb8674999c6bf94cdb3be
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests VPMU context is allocated lazily, during the first
access to VPMU MSRs. Since the leaf is typically queried before gu
Hi, Jan.
On Thu, Feb 16, 2017 at 11:36 AM, Jan Beulich wrote:
On 15.02.17 at 18:43, wrote:
>> 1.
>> I need:
>> Allow P2M core on ARM to update IOMMU mapping from the first "p2m_set_entry".
>> I do:
>> I explicitly set need_iommu flag for *every* guest domain during
>> iommu_domain_init() on
flight 105835 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105835/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3)broken pass in 105815
test-amd64-i386-libvirt
>>> On 14.02.17 at 15:56, wrote:
> On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote:
>> Not so far. It appears to happen when grub clears the screen
>> before displaying its graphical menu, so I'd rather suspect an issue
>> with a graphics related change (the one you pointed out isn't).
flight 105833 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105833/
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 15 guest-localmigrate/x10
fail REGR. vs.
flight 105852 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105852/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
do_dm_op() expects (void *, size_t) pairs, but with nr being uint32_t
the type of the expression of xc_hvm_track_dirty_vram()'s last argument
to the function is only a 32 bits one. Neither C nor the ABI require
the compiler to promote the type beyond int.
Signed-off-by: Jan Beulich
--- a/tools/l
1 - 100 of 227 matches
Mail list logo
