Hi, Dmitry!
On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 05/30/2017 0
This run is configured for baseline tests only.
flight 71533 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71533/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
flight 110085 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110085/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f099211f2ebdadf61ae6416559220d69b788cd2b
baseline version:
xtf 2bcda1aa60cd0032ea7371
flight 110079 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 5 xen-install fail REGR. vs. 109754
test-amd64-amd64-pyg
flight 110076 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110076/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 21 leak-check/check fail REGR. vs. 110038
test-amd64-i386-xl-q
On Wed, Jun 07, 2017 at 06:48:51PM +0100, Ian Jackson wrote:
> Thanks to Konrad, who passed me his git branch under the table.
> I have tidied up some loose ends, and tested it with my xen.git
> Makefile patches.
Yeey! Thank you for taking them over.
>
> Konrad, would you please take a look at th
flight 110078 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110078/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b941c34ef859971e29683ffb57c309e24e6a96be
baseline version:
ovmf 9c94cc2ca270c2a9121c4
flight 110071 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110071/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 110027
Tests which did not succeed
On 06/07/2017 03:14 PM, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption bit that indicates
> the PGD is encrypted. The encryption bit should not be used when creating
> a virtual address for the PGD table.
>
> Create a new function, read_cr3_pa(), that will extract the
flight 110097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110097/
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
test-amd64-amd64-libvirt 12 mig
flight 110065 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110065/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 110026
test-armhf-armhf-libvirt-xsm 13 saveresto
Hi,
I am working on creating a patch to aid in containing the unrecoverable
AER errors generated by PCI devices assigned to guests in passthrough
mode.
The overall approach is as follows:
1. Change the BIOS settings such that the AER error handling is delegated
to the host.
2. Change the xe
Ian Jackson writes ("[OSSTEST PATCH v4 00/11] livepatch test support"):
> Thanks to Konrad, who passed me his git branch under the table.
> I have tidied up some loose ends, and tested it with my xen.git
> Makefile patches.
Oh, I should probably share this test report.
(Sorry, the log url is still
flight 110092 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110092/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 9 debian-install fail REGR. vs. 110087
Tests which
On Wed, 7 Jun 2017, Juergen Gross wrote:
> On 06/06/17 21:08, Stefano Stabellini wrote:
> > On Tue, 6 Jun 2017, Juergen Gross wrote:
> >> On 06/06/17 18:39, Stefano Stabellini wrote:
> >>> On Tue, 6 Jun 2017, Juergen Gross wrote:
> On 26/05/17 21:01, Stefano Stabellini wrote:
> > On Fri, 2
On Wed, 7 Jun 2017, Sergey Dyasli wrote:
> Change the third parameter to be the required struct xen_dm_op_buf *
> instead of a generic void * (which blindly accepts any pointer).
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Stefano Stabellini
> ---
> v1 --> v2:
> - Replaced "#include " with
flight 110063 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110063/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-xsm 3 host-install(3) broken in 110044 pass in 110063
test-arm64-arm64-xl-credit2
On Wed, 7 Jun 2017, Bhupinder Thakur wrote:
> Hi Stefano,
>
> Thanks for your comments.
>
> >> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> >> index c5dd08d..db73e10 100644
> >> --- a/tools/console/daemon/io.c
> >> +++ b/tools/console/daemon/io.c
> >> @@ -90,12 +90,15 @@ s
Signed-off-by: Konrad Rzeszutek Wilk
---
v4: Split off from the patch introducing target_cmd_output_root_status.
Rewrote all the comments to be true.
---
Osstest/TestSupport.pm | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
ind
From: Konrad Rzeszutek Wilk
Set it to true on branches that support livepatching (Xen versions 4.9
and higher). Currently nothing reads this variable, so no overall
functional change.
Changes to the flights are as follows. On these branches:
osstest
xen-4.8-testing
xen-
From: Konrad Rzeszutek Wilk
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Ian Jackson
---
v4: Tiny style change.
---
sg-run-job | 6 ++
1 file changed, 6 insertions(+)
diff --git a/sg-run-job b/sg-run-job
index ceb7980..35bc785 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -441,6 +441
Previously, if it didn't contain a `.', it would be taken as a flight
name and completed with the old job name. (This was not documented.)
This meant that there was no way to adjust to refer to a differnet job
in the flight being manipulated without specifying the flight number
(which is not desi
This is mostly useful in ad-hoc situations. For example, it can be
usefully used with ./mg-adjust-flight-makexrefs.
Signed-off-by: Ian Jackson
---
v4: New patch, which helps with issues I tripped over while trying
to ad-hoc test the livepatch series.
---
sg-check-tested | 4
1 file ch
From: Konrad Rzeszutek Wilk
Livepatch compiles and works on x86/ARM{32|64} so we can enable it
in the Xen config when requested by the enable_livepatch runvar.
When we are trying to build with enable_livepatch, run `make
dist-tests' as well, to ship the test cases. This depends on a
correspondi
From: Konrad Rzeszutek Wilk
Similar to target_cmd_root_status except it outputs both output _and_
status.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Ian Jackson
---
v2: Initial posting
v3: Sprinkle some comments.
v4: Move doc comments out of this patch (and rewrite them).
Edit com
From: Konrad Rzeszutek Wilk
So we can have "test-amd64-amd64-livepatch" or such.
Changes to the flights are as follows. In these branches:
osstest
xen-4.8-testing
xen-4.9-testing
xen-unstable
add the new jobs:
test-amd64-amd64-livepatch
test-amd64-i386-livepatch
which lo
From: Konrad Rzeszutek Wilk
There are 37 of the test-cases in there. Before we run
any of them we verify that the payload files are present
in /usr/lib/debug.
If so we go through all of the test-cases.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Ian Jackson
---
v1: Initial submission.
From: Konrad Rzeszutek Wilk
But a bit different. Here is the syntax:
usage: lab [-v] arguments
arguments are: {on|off|reboot|info|clear|pxe} tstXXX
or: pxe tstXXX [baudrate]
or: connect tstXXX [baudrate]
or: speed tstXXX baudrate
or: setpxe tst
Thanks to Konrad, who passed me his git branch under the table.
I have tidied up some loose ends, and tested it with my xen.git
Makefile patches.
Konrad, would you please take a look at this to make sure you don't
think I've broken anything and that my changes look sane ? In
particlar the patches
Hi,
On 02/06/17 18:12, Julien Grall wrote:
> Hi Andre,
>
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>> pair and actually instantiates LPI interrupts. MAPI is just a variant
>> of this comment, where the LPI ID is the sam
From: Konrad Rzeszutek Wilk
All the different target_cmd_* end up calling tcmdex
which has the unfortunate side-effect of calling 'die' if
the SSH sessions results in any return code not zero.
That is fine, except for tests where we want to get a non-zero
return value.
This patch adds the $bads
On 07/06/17 18:46, Stefano Stabellini wrote:
On Wed, 7 Jun 2017, Punit Agrawal wrote:
Stefano Stabellini writes:
On Tue, 6 Jun 2017, Julien Grall wrote:
On 26/05/17 12:14, Punit Agrawal wrote:
Hi,
Hi,
It looks like this patch series has been fully acked. Can someone apply it?
Done. I
On Wed, 7 Jun 2017, Punit Agrawal wrote:
> Stefano Stabellini writes:
>
> > On Tue, 6 Jun 2017, Julien Grall wrote:
> >> On 26/05/17 12:14, Punit Agrawal wrote:
> >> > Hi,
> >>
> >> Hi,
> >>
> >> It looks like this patch series has been fully acked. Can someone apply it?
> >
> > Done. It was ap
Hi. I found this patch in the git branch you passed me. I'm not sure
if you intended this patch for upstream, but it has your s-o-b so I
guess so. For reasons that will become clear I have chosen to
git-send-email it to myself, so that I may reply.
Ian Jackson writes ("[OSSTEST PATCH] standalon
flight 110060 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110060/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR. vs. 109994
test-amd64-amd64-li
Hi
On Wed, Jun 7, 2017 at 8:57 PM Anthony PERARD
wrote:
> On Mon, May 29, 2017 at 12:45:43PM +0400, Marc-André Lureau wrote:
> > Move all the fronted struct and methods to a seperate unit. This avoids
> > accidentally mixing backend and frontend calls, and helps with
> readibilty.
> >
> > Make q
>
> -bool_t
> -svm_vmcb_isvalid(const char *from, struct vmcb_struct *vmcb,
> - bool_t verbose)
> +bool svm_vmcb_isvalid(const char *from, const struct vmcb_struct *vmcb,
> + const struct vcpu *v, bool verbose)
> {
> -bool_t ret = 0; /* ok */
> +bool
On 06/07/2017 10:07 AM, Jan Beulich wrote:
> - constify parameter
> - use accessors
> - drop stray casts
> - adjust formatting
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lis
On 06/07/2017 10:04 AM, Jan Beulich wrote:
> Prevent accidental mistakes by not requiring explicit types to be
> specified in the macro invocations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@list
On 06/07/2017 10:04 AM, Jan Beulich wrote:
> This is particularly relevant for the SET form, to ensure proper clean
> bits tracking (albeit in the case here it's benign as CPL and other
> segment register attributes share a clean bit).
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
flight 110087 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110087/
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
test-amd64-amd64-libvirt 12 mig
On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
> >On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> >>>On Fri,
On Wed, Jun 07, 2017 at 09:21:13AM +0530, Bhupinder Thakur wrote:
> > Is there a reason why we have one xce_pollfd_idx, xce_handle,
> > next_period and event_count per domain, rather than per console?
> >
> > It is strange to set xce_pollfd_idx if at least one console of the
> > domain has enough b
On Tue, Jun 06, 2017 at 10:55:26PM +0530, Bhupinder Thakur wrote:
> This patch finally adds the support for vuart console.
>
> Signed-off-by: Bhupinder Thakur
> ---
> CC: ij
> CC: wl
> CC: ss
> CC: jg
>
> Changes since v3:
> - The changes in xenconsole have been split into four patches. This is
On Tue, Jun 06, 2017 at 10:55:20PM +0530, Bhupinder Thakur wrote:
> Allocate a new gfn to be used as a ring buffer between xenconsole
> and Xen for sending/receiving pl011 console data.
>
> Signed-off-by: Bhupinder Thakur
Acked-by: Wei Liu
___
Xen-de
On Mon, May 29, 2017 at 12:45:43PM +0400, Marc-André Lureau wrote:
> Move all the fronted struct and methods to a seperate unit. This avoids
> accidentally mixing backend and frontend calls, and helps with readibilty.
>
> Make qemu_chr_replay() a macro shared by both char and char-fe.
>
> Export
There has been a report about a deadlock in the xenbus driver:
[ 247.979498] ==
[ 247.985688] WARNING: possible circular locking dependency detected
[ 247.991882] 4.12.0-rc4-00022-gc4b25c0 #575 Not tainted
[ 247.997040] --
>>> On 07.06.17 at 17:55, wrote:
> On Wed, 2017-06-07 at 08:46 -0600, Jan Beulich wrote:
>> > > > On 01.06.17 at 19:33, wrote:
>> >
>> > In fact, when calling __trace_var() directly, we can
>> > assume that tb_init_done has been checked to be true,
>> > and the if is hence redundant.
>>
>> The
>>> On 07.06.17 at 17:44, wrote:
> On 07/06/17 14:40, Jan Beulich wrote:
> On 07.06.17 at 15:04, wrote:
>>> Furthermore, in a following patch, I intend to make a similar adjustment as
>>> http://xenbits.xen.org/gitweb/?p=xtf.git;a=commitdiff;h=f099211f2ebdadf61ae6
>>>
>>> 416559220d69b788cd
On 07/06/17 15:51, Ian Jackson wrote:
> This allows CI systems such as osstest which are trying to consume
> this to arrange for the files to be built, and output, without them
> having to have special knowledge of the details of Xen's build syste.
system.
~Andrew
___
>>> On 07.06.17 at 17:45, wrote:
> On Wed, 2017-06-07 at 09:05 -0600, Jan Beulich wrote:
>> > > > On 01.06.17 at 19:33, wrote:
>> > @@ -884,9 +919,13 @@ void do_IRQ(struct cpu_user_regs *regs)
>> > desc->rl_quantum_start = now;
>> > }
>> >
>> > -tsc_in = tb_init_do
On Wed, 2017-06-07 at 08:46 -0600, Jan Beulich wrote:
> > > > On 01.06.17 at 19:33, wrote:
> >
> > In fact, when calling __trace_var() directly, we can
> > assume that tb_init_done has been checked to be true,
> > and the if is hence redundant.
>
> The "assume" here worries me: What if there's a
Wei Liu writes ("Re: [PATCH for-4.9 0/4] Makefiles: Provide way to ship
livepatch tests"):
> Acked-by: Wei Liu
Thanks to everyone for the review and acks.
> +1 for this to go into 4.9 and be backported to 4.8.
Thanks.
Jan Beulich writes ("Re: [PATCH 3/4] xen/test/livepatch: Add xen_nop.livepa
On 07/06/17 15:31, Jan Beulich wrote:
On 07.06.17 at 16:23, wrote:
>> On 07/06/17 16:10, Jan Beulich wrote:
>> On 07.06.17 at 16:00, wrote:
Just saw the message:
[0.005227] mce: CPU supports 2 MCE banks
in the boot log of a pv domU (Linux 4.11). I really have
>>> On 07.06.17 at 17:40, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 June 2017 16:33
>>
>> Since you said it doesn't
>> make it to the point where Xen would do any normal output, have
>> you been able to narrow down how far it gets? I think this is one
>> of the few remaini
On 07/06/17 17:05, Andre Przywara wrote:
> Hi,
>
> when booting Linux 4.12-rc4 as Dom0 under a recent Xen HV I saw the
> following lockdep splat after running xencommons start:
>
> root@junor1:~# bash /etc/init.d/xencommons start
> Setting domain 0 name, domid and JSON config...
> [ 247.979498]
On 07/06/17 14:40, Jan Beulich wrote:
On 07.06.17 at 15:04, wrote:
>> RFC, because I'd also like to float the idea of making this adjustment as
>> well:
>>
>> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h
>> b/xen/arch/x86/x86_emulate/x86_emulate.h
>> index 3355c01..53a5480 100644
>>
On Wed, 2017-06-07 at 09:05 -0600, Jan Beulich wrote:
> > > > On 01.06.17 at 19:33, wrote:
> >
> > More specifically:
> > - the handling of the TRC_HW_IRQ_HANDLED is fixed, both in
> > xentrace_format and in xenalyze;
> > - simple events for recording when we enter and exit the
> > do_IRQ
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 June 2017 16:33
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel(xen-
> de...@lists.xenproject.org) ;
> 'BorisOstrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel] de
>>> On 07.06.17 at 17:06, wrote:
> On Wed, Jun 07, 2017 at 06:31:18AM -0600, Jan Beulich wrote:
> On 07.06.17 at 11:29, wrote:
>>> @@ -2266,8 +2267,10 @@ int __init intel_vtd_setup(void)
>>> * We cannot use posted interrupt if X86_FEATURE_CX16 is
>>> * not supported, since
>>> On 07.06.17 at 17:06, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 June 2017 13:56
>> >>> On 07.06.17 at 14:46, wrote:
>> > I guess I'm going to have to try to write some code to log values to
>> > the VGA buffer to see what is going on.
>>
>> Good luck!
>>
>
> That r
On Wed, Jun 07, 2017 at 03:51:28PM +0100, Ian Jackson wrote:
> I am trying to get the livepatches tested in osstest. As discussed, I
> would like the xen.git Makefiles to be able to ship the livepatch test
> files, so that osstest does not need to have too much special
> knowledge of the xen.git b
On Wed, Jun 07, 2017 at 06:31:18AM -0600, Jan Beulich wrote:
On 07.06.17 at 11:29, wrote:
>> @@ -2266,8 +2267,10 @@ int __init intel_vtd_setup(void)
>> * We cannot use posted interrupt if X86_FEATURE_CX16 is
>> * not supported, since we count on this feature to
>>
>>> On 07.06.17 at 16:51, wrote:
> I am trying to get the livepatches tested in osstest. As discussed, I
> would like the xen.git Makefiles to be able to ship the livepatch test
> files, so that osstest does not need to have too much special
> knowledge of the xen.git build system.
>
> There are
On Wed, 2017-06-07 at 12:16 +0100, Julien Grall wrote:
> Hi Dario,
>
Hi,
> On 01/06/17 18:34, Dario Faggioli wrote:
> > diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> > index 2a06406..33b903e 100644
> > --- a/xen/common/spinlock.c
> > +++ b/xen/common/spinlock.c
> > @@ -150,7 +150,9
>>> On 07.06.17 at 16:51, wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -300,6 +300,7 @@ xen/test/livepatch/config.h
> xen/test/livepatch/xen_bye_world.livepatch
> xen/test/livepatch/xen_hello_world.livepatch
> xen/test/livepatch/xen_replace_world.livepatch
> +xen/test/livepatch/xen_nop.liv
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 June 2017 13:56
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel(xen-
> de...@lists.xenproject.org) ;
> 'BorisOstrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel] de
>>> On 01.06.17 at 19:34, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -98,6 +98,14 @@ config PERF_ARRAYS
> ---help---
> Enables software performance counter array histograms.
>
> +config TRACING
> + bool "Tracing"
> + default y
default DEBUG (you don't
On 07/06/17 16:07, Julien Grall wrote:
On 07/06/17 15:56, Sergej Proskurin wrote:
Hi Julien,
[...]
Also, a lot of the new defines you add are for TCR_EL1 and not TCR_EL2.
Please make the distinction in the name to avoid misusing them.
+
+#define TCR_TB_31 (31)
#ifdef CONFIG_
On 07/06/17 15:56, Sergej Proskurin wrote:
Hi Julien,
[...]
Also, a lot of the new defines you add are for TCR_EL1 and not TCR_EL2.
Please make the distinction in the name to avoid misusing them.
+
+#define TCR_TB_31 (31)
#ifdef CONFIG_ARM_64
#define TCR_PS(x) ((x)<<1
On Wed, Jun 07, 2017 at 03:51:28PM +0100, Ian Jackson wrote:
> I am trying to get the livepatches tested in osstest. As discussed, I
> would like the xen.git Makefiles to be able to ship the livepatch test
> files, so that osstest does not need to have too much special
> knowledge of the xen.git b
On Wed, Jun 07, 2017 at 03:51:32PM +0100, Ian Jackson wrote:
> In the toplevel Makefile, provide build-tests and install-tests
> targets which descend into xen/test. (dist-tests is provided
> automatically by the pattern rule, as is the convention here.)
>
> We have to set BASEDIR ourselves, and
On Wed, Jun 07, 2017 at 03:51:30PM +0100, Ian Jackson wrote:
> In xen/test/livepatch/Makefile:
>
> Provide a `build' target, as most of the
> subdir-invoking Makefiles elsewhere expect.
>
> In xen/test/Makefile:
>
> Replace the two open-coded targets with a generalised pattern rule
> whi
On Wed, Jun 07, 2017 at 03:51:31PM +0100, Ian Jackson wrote:
> CC: Konrad Rzeszutek Wilk
> Signed-off-by: Ian Jackson
Oh yes!
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 74747cb..5cae740 100644
Hi,
when booting Linux 4.12-rc4 as Dom0 under a recent Xen HV I saw the
following lockdep splat after running xencommons start:
root@junor1:~# bash /etc/init.d/xencommons start
Setting domain 0 name, domid and JSON config...
[ 247.979498] ==
[
On Wed, Jun 07, 2017 at 03:51:29PM +0100, Ian Jackson wrote:
> Dumping these patch files in /usr/lib/debug/xen-*.livepatch is a bit
> ugly.
Not really tied in where they go.
>
> Also, refactor the Makefile to have a LIVEPATCHES variable, to reduce
> repetition.
>
> CC: Konrad Rzeszutek Wilk
R
>>> On 01.06.17 at 19:33, wrote:
> More specifically:
> - the handling of the TRC_HW_IRQ_HANDLED is fixed, both in
>xentrace_format and in xenalyze;
> - simple events for recording when we enter and exit the
>do_IRQ function, as well as when we deal with a guest
>IRQ, are added;
On
Hi Julien,
[...]
>
> Also, a lot of the new defines you add are for TCR_EL1 and not TCR_EL2.
> Please make the distinction in the name to avoid misusing them.
>
>> +
>> +#define TCR_TB_31 (31)
>> #ifdef CONFIG_ARM_64
>> #define TCR_PS(x) ((x)<<16)
>> #define TCR_TBI
Dumping these patch files in /usr/lib/debug/xen-*.livepatch is a bit
ugly.
Also, refactor the Makefile to have a LIVEPATCHES variable, to reduce
repetition.
CC: Konrad Rzeszutek Wilk
Signed-off-by: Ian Jackson
---
xen/test/livepatch/Makefile | 19 +++
1 file changed, 11 inserti
CC: Konrad Rzeszutek Wilk
Signed-off-by: Ian Jackson
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 74747cb..5cae740 100644
--- a/.gitignore
+++ b/.gitignore
@@ -300,6 +300,7 @@ xen/test/livepatch/config.h
xen/test/livepatch/xen_bye_world.livepa
In xen/test/livepatch/Makefile:
Provide a `build' target, as most of the
subdir-invoking Makefiles elsewhere expect.
In xen/test/Makefile:
Replace the two open-coded targets with a generalised pattern rule
which descends into each of SUBDIRS. This allows `install' to work
too (it is a
In the toplevel Makefile, provide build-tests and install-tests
targets which descend into xen/test. (dist-tests is provided
automatically by the pattern rule, as is the convention here.)
We have to set BASEDIR ourselves, and use these curious runes, because
the convention in Makefiles under xen/
I am trying to get the livepatches tested in osstest. As discussed, I
would like the xen.git Makefiles to be able to ship the livepatch test
files, so that osstest does not need to have too much special
knowledge of the xen.git build system.
There are three preliminary patches which tidy up the x
>>> On 01.06.17 at 19:33, wrote:
> In fact, when calling __trace_var() directly, we can
> assume that tb_init_done has been checked to be true,
> and the if is hence redundant.
The "assume" here worries me: What if there's a single place
somewhere that a grep can't easily find where no check is
p
>>> On 01.06.17 at 19:33, wrote:
> In fact, right now, we read it at every iteration of the loop.
> The reason it's done like this is how context switch was handled
> on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
>
> However:
> 1) we don't have IA64 any longer, and all the
On 06/07/2017 07:46 AM, Anoob Soman wrote:
> A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
> interrupts,in a short period of time. All these evtchn:qemu-dm are bound
> to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
> In one configuration, irqbalan
>>> On 07.06.17 at 16:23, wrote:
> On 07/06/17 16:10, Jan Beulich wrote:
> On 07.06.17 at 16:00, wrote:
>>> Just saw the message:
>>>
>>> [0.005227] mce: CPU supports 2 MCE banks
>>>
>>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>>> the value of MCE handling
On 07/06/17 16:10, Jan Beulich wrote:
On 07.06.17 at 16:00, wrote:
>> Just saw the message:
>>
>> [0.005227] mce: CPU supports 2 MCE banks
>>
>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>> the value of MCE handling being active in this case. Shouldn't we sw
Wei Liu writes ("[PATCH] tools: bump some library version numbers to 4.10"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Thu, Jun 01, 2017 at 07:33:33PM +0200, Dario Faggioli wrote:
> Hello,
>
> While chasing and dealing with bugs, over this last period, I've found myself
> augmenting Xen with quite a few new tracing capabilities, especially focusing
> on:
> - IRQ being disabled and (re)enabled (in addition to t
flight 110083 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110083/
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
test-amd64-amd64-libvirt 12 mig
>>> On 07.06.17 at 16:00, wrote:
> Just saw the message:
>
> [0.005227] mce: CPU supports 2 MCE banks
>
> in the boot log of a pv domU (Linux 4.11). I really have problems to see
> the value of MCE handling being active in this case. Shouldn't we switch
> it off?
What's wrong with letting a
On Wednesday, 7 June 2017 11:52:34 PM AEST Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 07, 2017 at 10:36:58PM +1000, Steven Haigh wrote:
> > On Friday, 19 May 2017 1:28:46 AM AEST Juergen Gross wrote:
> > > Destroying a Xen guest domain while it was doing I/Os via xen-blkback
> > > leaked several re
- correct CR3, CR4, and EFER checks
- delete bogus nested paging check
- add vcpu parameter (to include in log messages) and constify vmcb one
- use bool/true/false
- use accessors
- adjust formatting
Signed-off-by: Jan Beulich
---
v2: Constrain CR3 checks to the case when CR0.PG is set. Change w
- constify parameter
- use accessors
- drop stray casts
- adjust formatting
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -26,60 +26,52 @@ static void svm_dump_sel(const char *nam
name, s->sel, s->attr.bytes, s->limit, s->ba
On 06/07/2017 04:07 AM, Jan Beulich wrote:
On 06.06.17 at 19:00, wrote:
>> FWIW, one of machines in our test farm choked on this very patch. I
>> don't remember details now but essentially it turned out that syslinux
>> (we are pxe-booting) could not handle changes in ELF sections layout
>> (
Prevent accidental mistakes by not requiring explicit types to be
specified in the macro invocations.
Signed-off-by: Jan Beulich
---
v2: Drop commented out accessors instead of adjusting them.
--- unstable.orig/xen/include/asm-x86/hvm/svm/vmcb.h2017-06-01
14:30:23.0 +0200
+++ unstab
This is particularly relevant for the SET form, to ensure proper clean
bits tracking (albeit in the case here it's benign as CPL and other
segment register attributes share a clean bit).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- unstable.orig/xen/arch/x86/hvm/svm/svm.c2017-0
Just saw the message:
[0.005227] mce: CPU supports 2 MCE banks
in the boot log of a pv domU (Linux 4.11). I really have problems to see
the value of MCE handling being active in this case. Shouldn't we switch
it off?
Juergen
___
Xen-devel mailing
1: use VMCB accessors
2: infer type in VMCB_ACCESSORS()
3: clean up svm_vmcb_dump()
4: clean up svm_vmcb_isvalid()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
1 - 100 of 183 matches
Mail list logo
