flight 122396 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122396/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d3180516f31b93f3dc14ebb0191cd78bcfc052d9
baseline version:
ovmf
flight 122391 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122391/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw broken
flight 122394 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122394/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
flight 122388 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122388/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 122286
flight 122421 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122421/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:
> > On 04/24/2018 11:35 PM, Dongwon Kim wrote:
> > > Had a meeting with Daniel and talked about bringing out generic
> > > part of hyper-dmabuf to the
flight 122416 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122416/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 25/04/18 17:58, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support
> matrix generation [and 4 more messages]"):
>> Thanks everyone. I have pushed this to staging-4.10, including the
>> patch 10/9.
>
> The first cut of the cron job is now
On 25/04/18 17:56, Ian Jackson wrote:
> I found this bug when trying to set up the cron job.
>
> Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support
matrix generation [and 4 more messages]"):
> Thanks everyone. I have pushed this to staging-4.10, including the
> patch 10/9.
The first cut of the cron job is now running. So far it is only
running off staging, and
On Wed, Apr 25, 2018 at 09:28:03AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 16:42, wrote:
> > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> >> > Without line numbers associated with at least the top stack trace entry
> >> > I can only guess what it
I found this bug when trying to set up the cron job.
Signed-off-by: Ian Jackson
---
docs/support-matrix-generate | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate
index b5ce3f4..a3d9332
On Tue, Apr 24, 2018 at 04:56:21PM +0100, Lars Kurth wrote:
> This follows up from a conversation after the April x86 community call, in
> which I had
> the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS
> copying
> the R section entries from Linux.git:MAINTAINERS
>>> On 25.04.18 at 17:26, wrote:
> Juergen Gross writes ("[PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11"):
>> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
>> order to produce an easier to read support HTML table.
>
> Reviwed-by: Ian Jackson
>>> On 25.04.18 at 16:42, wrote:
> On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
>> > Without line numbers associated with at least the top stack trace entry
>> > I can only guess what it might be - could you give the patch below a try?
>> > (This may not
Juergen Gross writes ("[PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11"):
> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
> order to produce an easier to read support HTML table.
Reviwed-by: Ian Jackson
An example of the resulting output is
Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
order to produce an easier to read support HTML table.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index
Hi Julien,
On Mon, Apr 23, 2018 at 1:46 PM, Julien Grall wrote:
> Hi,
>
> On 20/04/18 13:25, Mirela Simonovic wrote:
>>
>> Checking CPU errata should be done only when a CPU is initially booted.
>> It is assumed that the CPU which is hotplugged after the system/Xen boots,
Ian Jackson writes ("[PATCH for-4.10 0/9] SUPPORT.md backports to support
matrix generation"):
> This is a backport of my two recent series to fix bugs in SUPPORT.md,
> format it as part of the published docs, and use relative position of
> the `Status' stanza compared to descriptive text to
flight 122386 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122386/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
> On Apr 25, 2018, at 2:00 PM, Ian Jackson wrote:
>
> This turns all the things which were treated as caveats, but which
> don't need to be footnoted in the matrix, into descriptions.
>
> For the benefit of the support matrix generator, this patch (or a
> version of
flight 122412 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122412/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> > Without line numbers associated with at least the top stack trace entry
> > I can only guess what it might be - could you give the patch below a try?
> > (This may not be the final patch, as I'm afraid there may be some race
> >
Hi Julien,
On Wed, Apr 25, 2018 at 3:23 PM, Julien Grall wrote:
> Hi,
>
>
> On 25/04/18 14:09, Mirela Simonovic wrote:
>>
>> On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall
>> wrote:
>>>
>>> Hi Mirela,
>>>
>>>
>>> On 20/04/18 13:25, Mirela Simonovic
On 25/04/18 16:09, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH-for-4.10] adapt SUPPORT.md to match 4.11"):
>> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
>> order to produce an easier to read support HTML table.
>
> This does not seem to appply on top of my own
Juergen Gross writes ("[PATCH-for-4.10] adapt SUPPORT.md to match 4.11"):
> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
> order to produce an easier to read support HTML table.
This does not seem to appply on top of my own 4.10 series.
Ian.
Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series
"C")"):
> Aah, so on ARM we have no dom0 support?
No, that is a mistake.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Some tags have been changed in 4.11. Adapt the 4.10 ones to match in
order to produce an easier to read support HTML table.
Signed-off-by: Juergen Gross
---
SUPPORT.md | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index
On 25/04/18 15:54, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes
> (series "C")"):
>> On 25/04/18 15:43, George Dunlap wrote:
>>> 2. Backport all renames / reorganizations to all supported versions
>>
>> +1
>>
>> As this will only be more specific it
Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series
"C")"):
> On 25/04/18 15:43, George Dunlap wrote:
> > 2. Backport all renames / reorganizations to all supported versions
>
> +1
>
> As this will only be more specific it is a win. Again above example:
> How would
Ian Jackson writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series
"C")"):
> George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes
> (series "C")"):
> > 2. Backport all renames / reorganizations to all supported versions
...
> > I was initially opposed to #2, but I
George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series
"C")"):
> Right, so there are four options:
>
> 1. Never rename / reorganize SUPPORT.md categories
This is clearly unworkable.
> 3. Introduce some sort of “mapping” of options so that the table
> generator can
On 25/04/18 15:43, George Dunlap wrote:
>
>
>> On Apr 25, 2018, at 2:32 PM, Juergen Gross wrote:
>>
>> On 25/04/18 15:21, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes
>>> (series "C")"):
Not related to these patches, but:
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Juergen Gross
> Sent: 25 April 2018 13:43
> To: xen-devel
> Subject: [Xen-devel] Should PV frontend drivers trust the backends?
>
> This is a followup of
When global_log_dirty is enabled VRAM modification tracking never
worked correctly. The address that is passed to xen_hvm_modified_memory()
is not the effective PFN but RAM block address which is not the same
for VRAM.
We need to make a translation for this address into PFN using
physmap. Since
> On Apr 25, 2018, at 2:32 PM, Juergen Gross wrote:
>
> On 25/04/18 15:21, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes
>> (series "C")"):
>>> Not related to these patches, but:
>>>
>>> SUPPORT.md of 4.10 seems to have some
On 25/04/18 13:42, Juergen Gross wrote:
> This is a followup of a discussion on IRC:
>
> The main question of the discussion was: "Should frontend drivers
> trust their backends not doing malicious actions?"
>
> This IMO includes:
>
> 1. The data put by the backend on the ring page(s) is sane and
On 25/04/18 15:23, Ian Jackson wrote:
> Reported-by: Juergen Gross
> Signed-off-by: Ian Jackson
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
On 25/04/18 15:21, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes
> (series "C")"):
>> Not related to these patches, but:
>>
>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
>> want to change those? This might result in a more
Reported-by: Juergen Gross
Signed-off-by: Ian Jackson
---
SUPPORT.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 0d2db1f..f85dda8 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -653,7 +653,7 @@ See
Hi,
On 25/04/18 14:09, Mirela Simonovic wrote:
On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall wrote:
Hi Mirela,
On 20/04/18 13:25, Mirela Simonovic wrote:
When a CPU is hot-unplugged the maintenance interrupt has to be
released in order to free the memory that was
>>> On 25.04.18 at 14:59, wrote:
> This is a backport of my two recent series to fix bugs in SUPPORT.md,
> format it as part of the published docs, and use relative position of
> the `Status' stanza compared to descriptive text to indicate whether
> the text is a caveat
Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series
"C")"):
> Not related to these patches, but:
>
> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we
> want to change those? This might result in a more readable table.
>
> e.g.:
>
> 4.10: ###
flight 122385 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken in 122354
test-xtf-amd64-amd64-4 50
On 25/04/18 15:04, Ian Jackson wrote:
> I was just testing the results of my backports of the SUPPORT.md
> series to 4.10 - just sent, under the Subject line:
> [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation
>
> I found a bug in the support matrix generator. Sadly the
Hi Julien,
On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall wrote:
> Hi Mirela,
>
>
> On 20/04/18 13:25, Mirela Simonovic wrote:
>>
>> When a CPU is hot-unplugged the maintenance interrupt has to be
>> released in order to free the memory that was allocated when the CPU
>> was
We are going to want to add a call site for this.
No functional change.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 48 +++-
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/docs/parse-support-md
I was just testing the results of my backports of the SUPPORT.md
series to 4.10 - just sent, under the Subject line:
[PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation
I found a bug in the support matrix generator. Sadly the bug was not
evident without the backported
Each document has its own objects in @insections. Only the first
RealSect encountered ends up in the main $toplevel_sectlist tree.
This means that trying to unify the Caveats information for all
version in the RealSect (the $insection) does not work. The caveats
for all versions that aren't the
From: DavidWang
Zhaoxin is a x86 IC designer. Its SOC products support both CPU
virtualization and I/O virtualization, which are compatible with Intel
VMX and VT-d respectively. Zhaoxin has 'Shanghai' CPU vendor ID.
Signed-off-by: DavidWang
---
This turns all the things which were treated as caveats, but which
don't need to be footnoted in the matrix, into descriptions.
For the benefit of the support matrix generator, this patch (or a
version of it) should be backported to 4.10.
Signed-off-by: Ian Jackson
We are going to want to format SUPPORT.md which does not match the
filename patterns in docs/. So provide a way to make an ad-hoc rule
using pandoc with the standard options.
No functional change in this patch.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: George Dunlap
Acked-by: Lars Kurth
(cherry picked from commit ebbd0299089a698c39d4ced966df5831944b4305)
---
SUPPORT.md | 2 +-
1
Continuations of bullet list items must be indented by exactly 4
spaces (according to pandoc_markdown(5) on Debian jessie).
This is most easily achieved by making the bullet list items have two
spaces before the `*'.
Signed-off-by: Ian Jackson
Release-acked-by:
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
(cherry picked from commit 2e9aeb6f40eaf13c20231ec91301be74a19152ad)
---
SUPPORT.md | 5 +
1 file changed, 5 insertions(+)
diff --git a/SUPPORT.md b/SUPPORT.md
index 3429afb..0d2db1f
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
(cherry picked from commit 7782db9260d4c6499458de4e8d9866bc0427e143)
[ Combined with: ]
docs/gen-html-index: Make HTML::TreeBuilder::XPath
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
(cherry picked from commit f246d42665a6023c248c5b3e374da5691df63f6f)
---
docs/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
There are none yet.
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Acked-by: Lars Kurth
(cherry picked from commit 1e4a834a8f5d970e68cff6d9c16710194bc46537)
---
docs/gen-html-index | 4
1 file changed, 4
This is a backport of my two recent series to fix bugs in SUPPORT.md,
format it as part of the published docs, and use relative position of
the `Status' stanza compared to descriptive text to indicate whether
the text is a caveat that deserves a footnote.
Most of this is uncontroversial and I
This commits (more or less) this file to be processed with pandoc,
rather than other markdown processors. There is, unfortunately, no
widely-accepted way to declare a title for the document.
I tested feeding the document to markdown(1) on Debian jessie and it
reproduced the % line as if it were
On 25/04/18 12:08, Petr Tesarik wrote:
> Xen PV domains cannot shut down and start a crash kernel. Instead,
> the crashing kernel makes a SCHEDOP_shutdown hypercall with the
> reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
> arch/x86/xen/enlighten_pv.c.
>
> A crash kernel
flight 74641 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74641/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74632
This is a followup of a discussion on IRC:
The main question of the discussion was: "Should frontend drivers
trust their backends not doing malicious actions?"
This IMO includes:
1. The data put by the backend on the ring page(s) is sane and
consistent, meaning that e.g. the response
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-259
version 2
x86: PV guest may crash Xen with XPTI
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-258
version 2
Information leak via crafted user-supplied CDROM
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
From: Gao Chao
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs
On Mon, Apr 23, 2018 at 6:14 PM, Lars Kurth wrote:
> ## Summary/Recommendation
>
> Assessment by Lars Kurth, Community Manager:
>
> _Given the maturity of the drivers and thus limited need to fix issues or
> develop new features,
> I would recommend to graduate the
On Wed, Apr 25, 2018 at 09:16:59AM +0100, Andrew Cooper wrote:
> Manuel: As a tangentially related question, does NetBSD ever try to page
> out its LDT?
AFAIK no, LDTs are allocated as kernel wired memory
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours
On Wed, Apr 25, 2018 at 12:35:11PM +0200, Olaf Hering wrote:
> Am Wed, 25 Apr 2018 11:31:25 +0100
> schrieb Wei Liu :
>
> > My bad. Yes, they are converted to int, not unsigned int.
>
> Hopefully that happens only if the target is int, not if all involved
> variables are
On Wed, Apr 25, 2018 at 12:58:47AM -0600, Jan Beulich wrote:
> >>> On 24.04.18 at 18:06, wrote:
> > Hello,
> > I tested xen 4.11.0 rc1 with NetBSD as dom0.
> > I could boot a NetBSD PV domU without problem, but at shutdown time
> > (poweroff
> > in the domU), I got a Xen
On 25/04/18 11:34, Mirela Simonovic wrote:
Hi Julien,
You may have missed this one. Should we try using notifiers here as well?
Yes, I assumed this was implied by my comments previously, so I skipped
the patch. Sorry for that.
Cheers,
Thanks,
Mirela
On Fri, Apr 20, 2018 at 2:25 PM,
Am Wed, 25 Apr 2018 11:31:25 +0100
schrieb Wei Liu :
> My bad. Yes, they are converted to int, not unsigned int.
Hopefully that happens only if the target is int, not if all involved variables
are short.
Unless there are objections I will prepare a patch to deal with
Hi Julien,
You may have missed this one. Should we try using notifiers here as well?
Thanks,
Mirela
On Fri, Apr 20, 2018 at 2:25 PM, Mirela Simonovic
wrote:
> When a CPU is hot-unplugged timer interrupts have to be released
> in order to free the memory that was
On Wed, Apr 25, 2018 at 04:26:06AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 12:06, wrote:
> > On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote:
> >> Am Wed, 25 Apr 2018 09:59:23 +0100
> >> schrieb Wei Liu :
> >>
> >> > Do you have the
>>> On 25.04.18 at 12:06, wrote:
> On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote:
>> Am Wed, 25 Apr 2018 09:59:23 +0100
>> schrieb Wei Liu :
>>
>> > Do you have the full diff of your changes?
>>
>> Not right now. But without 'val', or val
flight 122409 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122409/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 27170adb54a558e11defcd51989326a9beb95afe
baseline version:
xen
Xen PV domains cannot shut down and start a crash kernel. Instead,
the crashing kernel makes a SCHEDOP_shutdown hypercall with the
reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
arch/x86/xen/enlighten_pv.c.
A crash kernel reservation is merely a waste of RAM in this case. It
On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote:
> Am Wed, 25 Apr 2018 09:59:23 +0100
> schrieb Wei Liu :
>
> > Do you have the full diff of your changes?
>
> Not right now. But without 'val', or val being uint, the same error happens
> in f():
>
> #include
>
>>> On 25.04.18 at 11:04, wrote:
> Am Wed, 25 Apr 2018 09:59:23 +0100
> schrieb Wei Liu :
>
>> Do you have the full diff of your changes?
>
> Not right now. But without 'val', or val being uint, the same error happens
> in f():
>
> #include
> void
On 04/25/2018 12:02 PM, Takashi Iwai wrote:
On Wed, 25 Apr 2018 10:26:34 +0200,
Oleksandr Andrushchenko wrote:
On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote:
On 04/24/2018 06:02 PM, Takashi Iwai wrote:
On Tue, 24 Apr 2018 16:58:43 +0200,
Oleksandr Andrushchenko wrote:
On 04/24/2018
Am Wed, 25 Apr 2018 09:59:23 +0100
schrieb Wei Liu :
> Do you have the full diff of your changes?
Not right now. But without 'val', or val being uint, the same error happens in
f():
#include
void f(void)
{
unsigned short req_prod = 0, req_cons = 65400;
On Wed, 25 Apr 2018 10:26:34 +0200,
Oleksandr Andrushchenko wrote:
>
> On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote:
> > On 04/24/2018 06:02 PM, Takashi Iwai wrote:
> >> On Tue, 24 Apr 2018 16:58:43 +0200,
> >> Oleksandr Andrushchenko wrote:
> >>> On 04/24/2018 05:35 PM, Takashi Iwai
On Wed, Apr 25, 2018 at 09:39:24AM +0200, Olaf Hering wrote:
> Am Wed, 25 Apr 2018 09:28:38 +0200
> schrieb Juergen Gross :
>
> > Why? (u16)0 - (u16)65400 == 136
>
> My helloworld.c shows that ushort gets promoted to uint, unless it is done
> like that:
>
> - if
On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote:
On 04/24/2018 06:02 PM, Takashi Iwai wrote:
On Tue, 24 Apr 2018 16:58:43 +0200,
Oleksandr Andrushchenko wrote:
On 04/24/2018 05:35 PM, Takashi Iwai wrote:
On Tue, 24 Apr 2018 16:29:15 +0200,
Oleksandr Andrushchenko wrote:
On 04/24/2018
On 04/24/2018 03:50 PM, Mirela Simonovic wrote:
Hi Julien,
Hi,
Sorry I forgot to answer to some part of the e-mail.
On Mon, Apr 23, 2018 at 1:28 PM, Julien Grall wrote:
Hi Mirela,
On 20/04/18 13:25, Mirela Simonovic wrote:
diff --git a/xen/arch/arm/p2m.c
On 25/04/2018 07:58, Jan Beulich wrote:
On 24.04.18 at 18:06, wrote:
>> Hello,
>> I tested xen 4.11.0 rc1 with NetBSD as dom0.
>> I could boot a NetBSD PV domU without problem, but at shutdown time
>> (poweroff
>> in the domU), I got a Xen panic:
>> (XEN) Assertion
On 04/25/2018 09:49 AM, Jan Beulich wrote:
On 24.04.18 at 20:51, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr,
>> uint64_t *msr_content)
>> switch (
flight 122382 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
test-xtf-amd64-amd64-3 50
On 25/04/2018 07:49, Jan Beulich wrote:
On 24.04.18 at 20:51, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr,
>> uint64_t *msr_content)
>> switch (
Am Wed, 25 Apr 2018 09:28:38 +0200
schrieb Juergen Gross :
> Why? (u16)0 - (u16)65400 == 136
My helloworld.c shows that ushort gets promoted to uint, unless it is done like
that:
- if (queue->tx.sring->req_prod - queue->tx.req_cons >
-
On 25/04/18 09:19, Olaf Hering wrote:
> With commit 48856286b64e ("xen/netback: shutdown the ring if it contains
> garbage.") a new check was added to xen-netback, which triggers for me.
>
> Since there are bugs in ring buffer handling I tried to trigger them earlier
> by changing RING_IDX from
>>> On 24.04.18 at 20:51, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr,
> uint64_t *msr_content)
> switch ( msr )
> {
> case MSR_IA32_SYSENTER_CS:
On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:
> On 04/24/2018 11:35 PM, Dongwon Kim wrote:
> > Had a meeting with Daniel and talked about bringing out generic
> > part of hyper-dmabuf to the userspace, which means we most likely
> > reuse IOCTLs defined in xen-zcopy for
flight 122383 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122383/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
On 04/24/2018 11:35 PM, Dongwon Kim wrote:
Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.
I will still have kernel side API, so
95 matches
Mail list logo