We updated these patchs about adding Nested test job into OSSTest.
Nested virtualization is the function of running a hypervisor inside a virtual
machine.
The hypervisor that runs on the real hardware is called a level 0 or L0;
The hypervisor that runs as a guest inside L0 is called level 1 or L1
From: "longtao.pang"
This patch is used for inserting nested test job name and runvars into
standalone.db database after execute command './standalone-reset'.
---
make-flight | 19 +++
mfi-common |8
2 files changed, 27 insertions(+)
diff --git a/make-flight b/
From: "longtao.pang"
This patch is used for preparing and installing L1 guest VM inside L0 system
on testhost machine.
---
Osstest/Debian.pm | 25 +++--
Osstest/TestSupport.pm| 31 +-
sg-run-job|5 +
ts-nested-L1-debian-install-pa
From: "longtao.pang"
This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM,
and then reboot L1 guest into xen kernel.
---
sg-run-job|1 +
ts-nested-L1-debian-install-part2 | 364 +
2 files changed, 365 insertion
From: "longtao.pang"
This patch is used for installing L2 guest VM inside L1 guest VM.
---
sg-run-job|2 +
ts-debian-install | 166 +
2 files changed, 132 insertions(+), 36 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index
flight 31883 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31883/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs.
31811
test-amd64-i3
>>> On 11/28/2014 at 02:14 AM, in message
, Stefano
Stabellini wrote:
> On Mon, 7 Jul 2014, Chunyan Liu wrote:
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index addacdb..4f1cbd2 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -479,6
Found by Stefano, this chunk of the patch was never applied to
xen-unstable (commit 11dffa2359e8a2629490c14c029c7c7c777b3e47),
see http://marc.info/?l=qemu-devel&m=140471493425353&w=2.
Signed-off-by: Chunyan Liu
---
tools/libxl/libxl_dm.c | 9 +
1 file changed, 9 insertions(+)
diff --gi
On 11/27/2014 07:50 PM, Andrew Cooper wrote:
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
Some folks had reported that some xen hypercalls take a long time
If hardware support the 1GB pages, expose the feature to guest by
default. Users don't have to use a 'cpuid= ' option in config fil
e to turn it on.
Signed-off-by: Liang Li
Signed-off-by: Yang Zhang
---
tools/libxc/xc_cpuid_x86.c | 3 +++
xen/arch/x86/hvm/hvm.c | 2 +-
2 files changed, 4 in
I have done some network performance testing under XEN, and found the result
which is somehow strange:
When testing between Hosts (Sender and receiver servers are both booting
from kernel-default), running only one netperf process will be enough to reach
the upper limit of NIC. However, wh
flight 31881 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 3 host-install(3) broken REGR. vs. 31778
test-amd64-i386-q
flight 31877 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31877/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl9 guest-start fail baseline untested
test-amd64-i386-xl-credit2 11
>>> patch is ok?
>>
>> No - Tim having confirmed that shadow mode doesn't support 1Gb pages,
> the feature clearly must not be made visible for shadow mode guest.
>Indeed. Liang, Can you add the shadow mode check in the next version?
Ok , I will do it and resend the patch.
Migrations with xl migrate --debug will fail because debugging information
from the receiving process is written to the stdout channel. This channel
is also used for status messages so the migration will fail as the sending
process receives an unexpected message. This patch moves the debugging
flight 31873 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31873/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 31853
On Wed, 26 Nov 2014, Andrew Cooper wrote:
On 26/11/2014 20:51, M A Young wrote:
--- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig 2014-10-24 15:22:40.0
+0100
+++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c 2014-11-25 20:29:06.723856433
+000
0
@@ -383,7 +383,7 @@
Sadly, changing printf
On 27/11/14 18:36, Luis R. Rodriguez wrote:
> On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
>> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez"
>>>
>>> Some folks had reported that some xen hypercalls take a long time
>>> to complete when issued from
On Thu, Nov 27, 2014 at 1:36 PM, Luis R. Rodriguez wrote:
> I'm afraid we don't have much leg room.
Let me be clear, I still think putting some hypercalls in process
context *might help* but because of notes 1) and 2) I highlighted I
think this is the best we can do, with more information we shou
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> Some folks had reported that some xen hypercalls take a long time
>> to complete when issued from the userspace private ioctl mechanism,
>> this can
Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
See below, or the rest of the thread, for details. It's broken up
into 6 tiny patches for ease of review.
Ian Jackson writes ("[PATCH for-4.5 0/6] libxl: events: Tear down fd interests
when idle"):
> If libxl_event_register_c
No-one in their right mind would do this, and if they did everything
would definitely collapse. Arrange that if this happens, we crash
ASAP.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
inde
We want to have no fd events registered when we are idle.
In this patch, deal with the xenstore watch fd:
* Track the total number of active watches.
* When deregistering a watch, or when watch registration fails, check
whether there are now no watches and if so deregister the fd.
* On libxl tea
If libxl_event_register_callbacks is called with nonzero hooks while
any part of libxl has any fd interests registered internally, then:
* There is no way for libxl to notify the application that it wants
to be told about these fds, because the spec in the doc comment
says that the new hook
We want to have no fd events registered when we are idle. This
implies that we must be able to deregister our interest in the sigchld
self-pipe fd, not just modify to request no events.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_fork.c |9 +
1 file changed, 1 insertion(+), 8 d
We want to have no fd events registered when we are idle.
In this patch, deal with the evtchn fd:
* Defer setup of the evtchn handle to the first use.
* Defer registration of the evtchn fd; register as needed on use.
* When cancelling an evtchn wait, or when wait setup fails, check
whether t
libxl_event_register_callbacks cannot reasonably be called while libxl
is busy (has outstanding operations and/or enabled events).
This is because the previous spec implied (although not entirely
clearly) that event hooks would not be called for existing fd and
timeout interests. There is thus no
We want to have no fd events registered when we are idle.
Also, we should put back the default SIGCHLD handler. So:
* In libxl_ctx_free, use libxl_childproc_setmode to set the mode to
the default, which is libxl_sigchld_owner_libxl (ie `libxl owns
SIGCHLD only when it has active children')
flight 31871 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31871/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 3 host-install(3) broken REGR. vs. 31241
On Mon, 7 Jul 2014, Chunyan Liu wrote:
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index addacdb..4f1cbd2 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -479,6 +485,15 @@ static char **
> libxl__build_device_model_args_new(libxl__gc *gc,
> if (b
Hi,
On 25/11/14 17:44, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen
> context switch to an idle vCPU. Therefore Xen may receive a spurious
> timer interrupt. As the idle domain doesn't have vGIC, Xen will crash
> when trying to inject the interrupt with
flight 31864 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31864/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail in 31856 REGR. vs.
26303
Tests which are f
Il 27/11/2014 13:08, Xen.org security team ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-8867 / XSA-112
version 5
Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor
UPDATES IN VERS
On 27/11/14 15:28, Tim Deegan wrote:
> At 15:16 + on 27 Nov (1417097812), Andrew Cooper wrote:
>> On 27/11/14 15:00, Tim Deegan wrote:
>>> At 10:54 + on 21 Nov (1416563695), Andrew Cooper wrote:
On 21/11/14 10:43, Jan Beulich wrote:
On 20.11.14 at 19:28, wrote:
>> Should
On 27/11/14 15:23, George Dunlap wrote:
> On Tue, Nov 25, 2014 at 6:05 PM, Daniel De Graaf
> wrote:
>> When an unknown domctl, sysctl, or other operation is encountered in the
>> FLASK security server, use the allow_unknown bit in the security policy
>> (set by running checkpolicy -U allow) to de
At 15:16 + on 27 Nov (1417097812), Andrew Cooper wrote:
> On 27/11/14 15:00, Tim Deegan wrote:
> > At 10:54 + on 21 Nov (1416563695), Andrew Cooper wrote:
> >> On 21/11/14 10:43, Jan Beulich wrote:
> >> On 20.11.14 at 19:28, wrote:
> Should the guest change the p2m structure durin
On Tue, Nov 25, 2014 at 6:05 PM, Daniel De Graaf wrote:
> When an unknown domctl, sysctl, or other operation is encountered in the
> FLASK security server, use the allow_unknown bit in the security policy
> (set by running checkpolicy -U allow) to decide if the permission should
> be allowed or de
On November 27, 2014 4:26:26 AM EST, Olaf Hering wrote:
>The already documented configure patch was not applied.
>Adjust documentation to describe existing behaviour.
>
>Signed-off-by: Olaf Hering
>Cc: Ian Campbell
>Cc: Ian Jackson
>Cc: Konrad Rzeszutek Wilk
Reviewed-by: me.
Don't need an re
On 27/11/14 15:00, Tim Deegan wrote:
> At 10:54 + on 21 Nov (1416563695), Andrew Cooper wrote:
>> On 21/11/14 10:43, Jan Beulich wrote:
>> On 20.11.14 at 19:28, wrote:
Should the guest change the p2m structure during live migration, the
toolstack ends up with a stale p2m with a n
At 10:32 + on 21 Nov (1416562351), Andrew Cooper wrote:
> On 21/11/14 05:41, Juergen Gross wrote:
> > On 11/20/2014 07:28 PM, Andrew Cooper wrote:
> >> Hello,
> >>
> >> Tim, David and I were discussing this over lunch. This email is a
> >> (hopefully accurate) account of our findings, and pote
On Nov 27, 2014 6:59 AM, Tim Deegan wrote:
>
> At 11:39 + on 27 Nov (1417084797), George Dunlap wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > I agree to the conditions in the XenProject Coverity contribution
> > guidelines [1].
> >
> > I'm a developer working f
El 26/11/14 a les 18.44, Wei Liu ha escrit:
> On Wed, Nov 26, 2014 at 06:32:21PM +0100, Roger Pau Monné wrote:
>> El 26/11/14 a les 17.55, Wei Liu ha escrit:
>>> Modify libxl and hotplug script to allow raw format file to use phy
>>> backend.
>>>
>>> The block script now tests the path and determin
At 10:54 + on 21 Nov (1416563695), Andrew Cooper wrote:
> On 21/11/14 10:43, Jan Beulich wrote:
> On 20.11.14 at 19:28, wrote:
> >> Should the guest change the p2m structure during live migration, the
> >> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> >> resulti
On Nov 27, 2014 8:06 AM, Jan Beulich wrote:
>
> >>> On 27.11.14 at 12:06, wrote:
> > Konrad: A release ack please. It would be nice if the command line
> > documentation was correct for 4.5.
>
> Honestly, unless really controversial, I don't think release acks are
> really needed for purely
flight 31863 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-multivcpu 7 debian-installfail REGR. vs. 31855
test-amd64-i386-xl-
flight 31867 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31867/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 host-install(3) broken REGR. vs. 31849
test-amd64-i386-pair
flight 31875 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31875/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 31851
>>> On 27.11.14 at 12:06, wrote:
> Konrad: A release ack please. It would be nice if the command line
> documentation was correct for 4.5.
Honestly, unless really controversial, I don't think release acks are
really needed for purely documentation changes.
Jan
flight 31874 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31874/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 3 host-install(3) broken REGR. vs. 31860
buil
>>> On 27.11.14 at 13:46, wrote:
> On 27/11/14 12:39, Jan Beulich wrote:
>> if ( unlikely(exit_reason == VMEXIT_INVALID) )
>> {
>
> I think it would be good to retain the printk here from previous
> versions of the patch, specifically identifies the below vmcb dump as
> caused by a fail
Hi Ian,
On 27/11/14 10:40, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:44 +, Julien Grall wrote:
>> ARMv8 model may not disable correctly the timer interrupt when Xen
>
> "correct disable"
>
>> context switch to an idle vCPU. Therefore Xen may receive a spurious
>
> "context switches" an
On 27/11/14 12:39, Jan Beulich wrote:
> This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
> guest upon problems occurring in user mode") and gets SVM in line with
> the resulting VMX behavior. This is because Andrew validly says
>
> "A failed vmentry is overwhelmingly likely to be
Hi Stefano,
On 27/11/14 10:51, Stefano Stabellini wrote:
> On Thu, 27 Nov 2014, Ian Campbell wrote:
>> On Tue, 2014-11-25 at 17:44 +, Julien Grall wrote:
>>> ARMv8 model may not disable correctly the timer interrupt when Xen
>>
>> "correct disable"
>>
>>> context switch to an idle vCPU. Theref
This reverts the VMX side of commit 28b4baac ("x86/HVM: don't crash
guest upon problems occurring in user mode") and gets SVM in line with
the resulting VMX behavior. This is because Andrew validly says
"A failed vmentry is overwhelmingly likely to be caused by corrupt
VMC[SB] state. As a result
These were initially flagged by the XenServer coverity scanning. It turns out
that they were being found by the upstream scan, but had been grouped with
Xend and listed as ignored, hiding them from the output. I have adjusted the
scan filters to not ignore the lowlevel libraries, and identified t
The code now now matches its comment, and will actually catch the case of a
bad xs handle.
Signed-off-by: Andrew Cooper
Coverity-ID: 1055948
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
CC: Xen Coverity Team
---
tools/python/xen/lowlevel/xs/xs.c |2 +-
1 file changed, 1 insertion(+), 1 d
Don't leak a 16k allocation if PyArg_ParseTupleAndKeywords() or the first
xc_readconsolering() fail. It is trivial to run throught the processes memory
by repeatedly passing junk parameters to this function.
In the case that the call to xc_readconsolering() in the while loop fails,
reinstate str
The error handling from a failed memory allocation should return
PyErr_SetFromErrno(xc_error_obj); rather than simply calling it and continuing
to the memcpy() below, with the dest pointer being NULL.
Furthermore, the context string is simply an input parameter to the hypercall,
and is not mutated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-8867 / XSA-112
version 5
Insufficient bounding of "REP MOVS" to MMIO emulated inside the hypervisor
UPDATES IN VERSION 5
Public release.
ISSUE DESCRIPTI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-8866 / XSA-111
version 3
Excessive checking in compatibility mode hypercall argument translation
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
At 11:39 + on 27 Nov (1417084797), George Dunlap wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
>
> I'm a developer working for Citrix Systems UK, Ltd. I've been active
> in the Xen community
On 27/11/14 11:39, George Dunlap wrote:
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
>
> I'm a developer working for Citrix Systems UK, Ltd. I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4 releases, and I
On 27/11/14 11:32, Ian Campbell wrote:
> On Thu, 2014-11-27 at 11:05 +, Andrew Cooper wrote:
>> On 27/11/14 09:49, Ian Campbell wrote:
>>> On Wed, 2014-11-26 at 14:26 +, Andrew Cooper wrote:
libxc (or some new alternative) should suck it up and gain some notion
of a stable API or
On Thu, 2014-11-27 at 11:39 +, George Dunlap wrote:
> I agree to the conditions in the XenProject Coverity contribution
> guidelines [1].
>
> I'm a developer working for Citrix Systems UK, Ltd. I've been active
> in the Xen community since 2006; I was release coordinator for the 4.3
> and 4.4
At 11:38 + on 27 Nov (1417084691), Jan Beulich wrote:
> >>> On 27.11.14 at 12:29, wrote:
> > At 11:16 + on 27 Nov (1417083414), Jan Beulich wrote:
> >> >>> On 27.11.14 at 11:26, wrote:
> >> > At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
> >> >> >>> On 26.11.14 at 18:43, wrot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I agree to the conditions in the XenProject Coverity contribution
guidelines [1].
I'm a developer working for Citrix Systems UK, Ltd. I've been active
in the Xen community since 2006; I was release coordinator for the 4.3
and 4.4 releases, and I am
>>> On 27.11.14 at 12:29, wrote:
> At 11:16 + on 27 Nov (1417083414), Jan Beulich wrote:
>> >>> On 27.11.14 at 11:26, wrote:
>> > At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
>> >> >>> On 26.11.14 at 18:43, wrote:
>> >> > My v1 patch only fixes the VMX side of things. SVM doesn
On Thu, 2014-11-27 at 11:05 +, Andrew Cooper wrote:
> On 27/11/14 09:49, Ian Campbell wrote:
> > On Wed, 2014-11-26 at 14:26 +, Andrew Cooper wrote:
> >> libxc (or some new alternative) should suck it up and gain some notion
> >> of a stable API or ABI (like the rest of the world appears to
At 11:16 + on 27 Nov (1417083414), Jan Beulich wrote:
> >>> On 27.11.14 at 11:26, wrote:
> > At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
> >> >>> On 26.11.14 at 18:43, wrote:
> >> > My v1 patch only fixes the VMX side of things. SVM doesn't explicitly
> >> > identify a failed v
On 27/11/14 11:16, Jan Beulich wrote:
On 27.11.14 at 11:26, wrote:
>> At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
>> On 26.11.14 at 18:43, wrote:
My v1 patch only fixes the VMX side of things. SVM doesn't explicitly
identify a failed vmentry and lets it fall into
>>> On 27.11.14 at 11:26, wrote:
> At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
>> >>> On 26.11.14 at 18:43, wrote:
>> > My v1 patch only fixes the VMX side of things. SVM doesn't explicitly
>> > identify a failed vmentry and lets it fall into the default case of the
>> > vmexit han
Thursday, November 27, 2014, 11:23:24 AM, you wrote:
> On Nov 24, 1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
>> Hello,
> Hi, hope the week is going well for everyone.
>> > >> As I was walking out the door I remembered I had been delinquent
>> > >> with information. The dom0 kernel i
* Add options whose code has been committed (without a patch to this file).
* Remove options which have been deleted (without a patch to this file).
* Tweak some formatting for consistency.
* Nuke some trailing whitespace.
I believe this document now identifies the exact set of command line option
On 27/11/14 09:49, Ian Campbell wrote:
> On Wed, 2014-11-26 at 14:26 +, Andrew Cooper wrote:
>> libxc (or some new alternative) should suck it up and gain some notion
>> of a stable API or ABI (like the rest of the world appears to be able to
>> manage), such that it is possible to compile with
Hello,
I know that xc_interface_open() can be safely called several times from
the same process, and that several processes can each have a bunch of
xc_interface handles open, and that I shouldn't use an xc_interface
inherited from the parent in a child process, because xenctrl.h says so.
Is it s
On Thu, 27 Nov 2014, Ian Campbell wrote:
> On Tue, 2014-11-25 at 17:44 +, Julien Grall wrote:
> > ARMv8 model may not disable correctly the timer interrupt when Xen
>
> "correct disable"
>
> > context switch to an idle vCPU. Therefore Xen may receive a spurious
>
> "context switches" and s/s
On Wed, 26 Nov 2014, Don Slutz wrote:
> On 11/26/14 13:17, Stefano Stabellini wrote:
> > On Tue, 25 Nov 2014, Andrew Cooper wrote:
> > > On 25/11/14 17:45, Stefano Stabellini wrote:
> > > > Increase maxmem before calling xc_domain_populate_physmap_exact to avoid
> > > > the risk of running out of g
>>> On 25.11.14 at 19:05, wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -135,6 +135,19 @@ static int get_irq_sid(int irq, u32 *sid, struct
> avc_audit_data *ad)
> return 0;
> }
>
> +static int avc_unknown_permission(const char* name, int id)
const char *name
>
On Tue, 2014-11-25 at 17:44 +, Julien Grall wrote:
> ARMv8 model may not disable correctly the timer interrupt when Xen
"correct disable"
> context switch to an idle vCPU. Therefore Xen may receive a spurious
"context switches" and s/spurious/unexpected/ (since spurious has a
specific meanin
At 08:42 + on 27 Nov (1417074133), Jan Beulich wrote:
> >>> On 26.11.14 at 18:43, wrote:
> > My v1 patch only fixes the VMX side of things. SVM doesn't explicitly
> > identify a failed vmentry and lets it fall into the default case of the
> > vmexit handler. As such, with v1, the infinite lo
On Nov 24, 1:28pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote:
> Hello,
Hi, hope the week is going well for everyone.
> > >> As I was walking out the door I remembered I had been delinquent
> > >> with information. The dom0 kernel is 32-bit 3.14.22 straight from
> > >> kernel.org under a 64-bi
On Wed, 2014-11-26 at 17:38 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] segv in osevent_release_nexus with
> libxl backend to libvirt"):
> > I don't know if this helps but on the 3 occasions I've just looked at
> > the ev passed to libxl__ev_fd_deregister contains an fd which
On Wed, 2014-11-26 at 14:26 +, Andrew Cooper wrote:
> libxc (or some new alternative) should suck it up and gain some notion
> of a stable API or ABI (like the rest of the world appears to be able to
> manage), such that it is possible to compile with an older header and
> use a newer .so at ru
>>> On 27.11.14 at 06:29, wrote:
> On 11/25/2014 03:00 AM, Jan Beulich wrote:
>> Okay, so it's not really the mwait-idle driver causing the regression,
>> but it is C-state related. Hence we're now down to seeing whether all
>> or just the deeper C states are affected, i.e. I now need to ask you
>
The already documented configure patch was not applied.
Adjust documentation to describe existing behaviour.
Signed-off-by: Olaf Hering
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
---
v3: reword as suggested by Konrad, trim Cc list
v2: resend due to lack of Cc: tags
INSTALL |
>>> On 26.11.14 at 15:39, wrote:
> On 11/25/2014 09:28 AM, Jan Beulich wrote:
>>
>>> +else
>>> +{
>>> +struct segment_register seg;
>>> +
>>> +hvm_get_segment_register(sampled, x86_seg_cs, &seg);
>>> +r->cs = seg.sel;
>>> +
>>> On 26.11.14 at 15:32, wrote:
> On 11/25/2014 08:49 AM, Jan Beulich wrote:
> On 17.11.14 at 00:07, wrote:
>>> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>>> switch ( vendor )
>>> {
>>> case X86_VENDOR_AMD:
>>> -if ( svm_vpmu_initialise(v, opt_vpmu
>>> On 26.11.14 at 15:26, wrote:
> On 11/25/2014 08:36 AM, Jan Beulich wrote:
>>
>>> +static long vpmu_sched_checkin(void *arg)
>>> +{
>>> +int cpu = cpumask_next(smp_processor_id(), &cpu_online_map);
>> unsigned int.
>>
>>> +int ret;
>>> +
>>> +/* Mode change shouldn't take more than
On Wed, 2014-11-26 at 19:03 +, Andrew Cooper wrote:
> On 26/11/14 18:41, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 26, 2014 at 06:24:11PM +, Dave Scott wrote:
> >>> On 26 Nov 2014, at 15:38, Zheng Li wrote:
> >>>
> >>> On 26/11/2014 15:09, Andrew Cooper wrote:
> This makes fields 0
>>> On 25.11.14 at 18:10, wrote:
> "Jan Beulich" writes:
>
> On 25.11.14 at 16:41, wrote:
>>> "Jan Beulich" writes:
>>> On 07.10.14 at 15:10, wrote:
> @@ -1764,11 +1765,28 @@ void free_domheap_pages(struct page_info *pg,
> unsigned int order)
> scrub = 1;
>
On Wed, 2014-11-26 at 17:39 +, Andrew Cooper wrote:
> > IMHO this is fine. It essentially means that for xl users there is some
> > delayed gratification wrt the promise of migration between non-alike
> > dom0s. The migration from 4.5(legacy)->4.6(v2) won't support such
> > migrations, but the
>>> On 26.11.14 at 18:43, wrote:
> My v1 patch only fixes the VMX side of things. SVM doesn't explicitly
> identify a failed vmentry and lets it fall into the default case of the
> vmexit handler. As such, with v1, the infinite loop still affects AMD
> hardware.
Right; I should have said "somet
在 11/26/2014 03:54 AM, Andrew Cooper 写道:
Hello,
The purpose of this email is to plan how to progress the migrationv2
series through to being merged. I believe I have CC'd everyone with a
specific interest in this area, but apologies if I have missed anyone.
Migration v2 is in exclusive use i
93 matches
Mail list logo
