flight 146060 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146060/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146057 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146057/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146056 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146056/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
test-amd64-amd64-xl-qemuu-ovmf-amd64 4 ho
On Mon, 13 Jan 2020, Julien Grall wrote:
> At the moment, the diagram is only indented with 2 spaces. So pandoc
> will try to badly interpret it and not display it correctly.
>
> Fix it by indenting all the block by 4 spaces (i.e an extra 2 spaces).
>
> Fixes: d661611d08 ("docs/markdown: Switch t
flight 146050 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146050/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 146006
test-amd64-amd64-xl-rtds 16 gues
flight 146055 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146055/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Mon, Jan 13, 2020 at 10:50 PM Rafael J. Wysocki wrote:
>
> On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra wrote:
> >
> > On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> > > For your original comment, just wanted to clarify the following:
> > >
> > > 1. After hibernation, the m
flight 146051 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
test-amd64-i386-xl-qemuu-ovmf-amd64 10 de
flight 146054 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146054/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
pandoc is currently failing to generate the pdf with the following
error:
! Undefined control sequence.
l.1048 metadata string format is: key=value\0
In this case, we want to print \0 so we need to backslash-escape the
first character.
Interestingly pandoc will not complain when creating html a
On 13/01/2020 21:57, Julien Grall wrote:
> At the moment, the diagram is only indented with 2 spaces. So pandoc
> will try to badly interpret it and not display it correctly.
>
> Fix it by indenting all the block by 4 spaces (i.e an extra 2 spaces).
>
> Fixes: d661611d08 ("docs/markdown: Switch to
At the moment, the diagram is only indented with 2 spaces. So pandoc
will try to badly interpret it and not display it correctly.
Fix it by indenting all the block by 4 spaces (i.e an extra 2 spaces).
Fixes: d661611d08 ("docs/markdown: Switch to using pandoc, and fix underscore
escaping")
Signed
On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra wrote:
>
> On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> > For your original comment, just wanted to clarify the following:
> >
> > 1. After hibernation, the machine can be resumed on a different but
> > compatible
> > host (these
On Mon, Jan 13, 2020 at 04:25:02PM -0500, Boris Ostrovsky wrote:
>
>
> On 1/10/20 10:43 PM, Marek Marczykowski-Górecki wrote:
> > @@ -117,6 +117,24 @@ static int command_write(struct pci_dev *dev, int
> > offset, u16 value, void *data)
> > pci_clear_mwi(dev);
> > }
> > + if (de
Hi all,
The main goal of this series is to make easier to understand and use
struct pirq. Patch #1 and #3 are cleanups.
Cheers,
Julien Grall (4):
xen/x86: Remove unused forward declaration in asm-x86/irq.h
xen/char: ehci: Directly include xen/timer.h rather rely on dependency
xen/domain: R
From: Julien Grall
The ehci char driver is using timers but relying on the header
xen/timer.h to be included via asm-x86/hvm/irq.h which is not even
directly included!
Future rework will reduce the number of places where asm-x86/hvm/irq.h
will be included. Include xen/timer.h directly to avoid a
From: Julien Grall
At the moment, alloc_pirq_struct() relies on the field 'arch' to be the
last member of the structure.
As this is used for computing the size of the structure, the value will
be miscomputed if a new field is added afterwards.
Such quirkiness makes quite difficult to understand
From: Julien Grall
None of the prototypes within the header asm-x86/irq.h actually requires
the forward declaration of "struct pirq". So remove it.
No functional changes intended.
Signed-off-by: Julien Grall
---
xen/include/asm-x86/irq.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/
From: Julien Grall
None of the supported architecture override alloc_pirq_struct() with
a macro. So remove the #ifdef surrounding the prototype.
Signed-off-by: Julien Grall
---
xen/include/xen/domain.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/xen/domain.h b/xen/include/
On 1/10/20 10:43 PM, Marek Marczykowski-Górecki wrote:
@@ -117,6 +117,24 @@ static int command_write(struct pci_dev *dev, int offset,
u16 value, void *data)
pci_clear_mwi(dev);
}
+ if (dev_data && dev_data->allow_interrupt_control) {
+ if ((cmd->val ^
Hi Paul,
On 13/01/2020 16:54, Durrant, Paul wrote:
-Original Message-
From: jandr...@gmail.com
Sent: 13 January 2020 16:16
To: Durrant, Paul
Cc: xen-devel ; Anthony PERARD
; Ian Jackson ; Wei
Liu
Subject: Re: [Xen-devel] [PATCH v2 4/6] libxl: allow creation of domains
with a specified
On 13/01/2020, 19:54, "George Dunlap" wrote:
> On Dec 30, 2019, at 7:32 PM, Lars Kurth wrote:
>
> From: Lars Kurth
>
> This guide covers the bulk on Best Practice related to code review
> It primarily focusses on code review interactions
> It also covers ho
flight 146053 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146053/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
> On Dec 30, 2019, at 7:32 PM, Lars Kurth wrote:
>
> From: Lars Kurth
>
> This guide covers the bulk on Best Practice related to code review
> It primarily focusses on code review interactions
> It also covers how to deal with Misunderstandings and Cultural
> Differences
>
> +### Avoid opinio
On Fri, Dec 27, 2019 at 11:09 AM Andrew Cooper
wrote:
>
> On 20/12/2019 16:23, Jan Beulich wrote:
> > On 16.09.2019 11:40, Jan Beulich wrote:
> >> Using memcpy() may result in multiple individual byte accesses
> >> (dependening how memcpy() is implemented and how the resulting insns,
> >> e.g. REP
On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk wrote:
>
> On Thu, Mar 21, 2019 at 11:09 PM Roger Pau Monné wrote:
> >
> > On Wed, Mar 20, 2019 at 01:28:47PM -0400, Jason Andryuk wrote:
> > > On Fri, Mar 15, 2019 at 12:28 PM Andrew Cooper
> > > wrote:
> > > >
> > > > On 15/03/2019 09:17, Paul Durr
flight 146052 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Mon, Jan 13, 2020 at 11:55 AM Durrant, Paul wrote:
>
> > -Original Message-
> > From: jandr...@gmail.com
> > Sent: 13 January 2020 16:16
> > To: Durrant, Paul
> > Cc: xen-devel ; Anthony PERARD
> > ; Ian Jackson ; Wei
> > Liu
> > Subject: Re: [Xen-devel] [PATCH v2 4/6] libxl: allow c
... rather than presuming that 16M will do. With this fixed, Xen is now
capable of booting even when its compiled size is larger than 16M.
On the EFI side, use l2e_add_flags() to reduce the code-generation overhead of
using l2e_from_paddr() twice.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulic
Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
C code has nevertheless caused several bugs I should have known better about,
and contributed to review confusion.
There are exactly 4 uses of these constants in asm code (and one is shortly
going to disappear).
Instea
Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
C code has nevertheless caused several bugs I should have known better about,
and contributed to review confusion.
There are exactly 4 uses of these constants in asm code (and one is shortly
going to disappear).
Instea
The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
total, which is a limit looking to be lifted.
Move l2_xenmap[] into the bss, and adjust both the BIOS and EFI paths to fill
it in dynamically, based on the final linked size of Xen. For current builds,
this reduces the n
Since c/s faa85d4fb3 "x86/boot: Don't map 0 during boot", l1_identmap no
longer has an alias mapped at 0, meaning that none of the l?_identmap[]
pagetables are actually an identity map.
Rename them to l?_directmap, which avoids any kind of implication that they
might be mapped at 0.
Signed-off-by
It turns out that the note in c/s a8d27a54cc9cc
Finally, leave a linker assert covering the fact that plenty of code blindly
assumes that Xen is less that 16M. This wants fixing in due course.
was easier to address than I had originally anticipated. This series does so.
The end result can
Am Mon, 13 Jan 2020 11:36:27 +0100
schrieb Olaf Hering :
> qemu-system-i386: Unknown savevm section type 111
Looks like hw/i386/pc_piix.c:xenfv_machine_options must set
m->smbus_no_migration_support to true.
Not sure why this remained unnoticed for so long.
Olaf
pgpffQqWBqgtH.pgp
Description:
Hi Marek,
Below is a report from 0day bot build w/ Clang. The warning looks
legit, can you please take a look? Apologies if this has already been
reported.
On Sat, Jan 11, 2020 at 7:48 AM kbuild test robot wrote:
>
> CC: kbuild-...@lists.01.org
> In-Reply-To: <20200111034347.5270-1-marma...@invis
This is a very common exit pattern. We are going to want to change
this pattern. So we should make it into a macro of its own.
No functional change.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_event.c| 18 ++
tools/libxl/libxl_fork.c | 6 ++
tools/libxl/libxl
No functional change.
Signed-off-by: Ian Jackson
---
v2: Now it takes a gc, not an egc.
---
tools/libxl/libxl_event.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 3e76fa5af5..45cc67942d 1006
We are going to use this a bit more widely. Make the name more
general.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl.c | 4 ++--
tools/libxl/libxl_event.c| 8
tools/libxl/libxl_internal.h | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/
If the application uses libxl_osevent_beforepoll, a similar hang is
possible to the one described and fixed in
libxl: event: Fix hang when mixing blocking and eventy calls
Application behaviour would have to be fairly unusual, but it
doesn't seem sensible to just leave this latent bug.
We fix t
We are going to want to change libxl__poller_wakeup to take a gc.
In theory there is a risk here that it would be called inappropriately
in a future patch but this seems unlikely.
Signed-off-by: Ian Jackson
---
v2: New patch
---
tools/libxl/libxl_aoutils.c | 2 +-
tools/libxl/libxl_disk.c
Track in userland whether the poller pipe is nonempty. This saves us
writing many many bytes to the pipe if nothing ever reads them.
This is going to be relevant in a moment, where we are going to create
a situation where this will happen quite a lot.
Signed-off-by: Ian Jackson
squash! libxl:
We are going to want to call this in the following situation:
* We have just set up an ao, which is to call back - so a
non-synchronous one. It ought not to call the application
back right away, so no egc.
* There is a libxl thread blocking somewhere but it is using
using an out of da
If the application calls libxl with ao_how==0 and also makes calls
like _occurred, libxl will sometimes get stuck.
The bug happens as follows (for example):
Thread A
libxl_do_thing(,ao_how==0)
libxl_do_thing starts, sets up some callbacks
libxl_do_thing exit path calls AO_I
The meat here, including a description of the bug, is in:
libxl: event: Fix hang when mixing blocking and eventy calls
Re v1 I wrote:
I suggest we try to convince ourselves of its correctness
via a second round of code review.
I put this into practice by writing an informal proof of correct
This is only for deregistration. We are going to add another variable
for new events, with different semantics, and this overly-general name
will become confusing.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_event.c| 8
tools/libxl/libxl_internal.h | 6 +++---
2 files changed,
If a timer event callback causes this poller to be woken (not very
unlikely) we would go round the poll loop twice rather than once.
Do the poller pipe emptying at the end; this is slightly more
efficient because it can't cause any callbacks, so it happens after
all the callbacks have been run.
(
> -Original Message-
> From: jandr...@gmail.com
> Sent: 13 January 2020 16:16
> To: Durrant, Paul
> Cc: xen-devel ; Anthony PERARD
> ; Ian Jackson ; Wei
> Liu
> Subject: Re: [Xen-devel] [PATCH v2 4/6] libxl: allow creation of domains
> with a specified or random domid
>
> On Thu, Jan 9,
On 13.01.2020 17:02, Andrew Cooper wrote:
> My recent boot pagetable changes have caused me to work with the EFI
> build of Xen rather more than previously.
>
> First, there is a dependency tracking bug in the build system. Edits to
> xen/arch/x86/efi/efi-boot.h don't cause xen.efi to be regenera
flight 146049 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146049/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146047 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On Thu, Jan 9, 2020 at 6:50 AM Paul Durrant wrote:
>
> This patch adds a 'domid' field to libxl_domain_create_info and then
> modifies do_domain_create() to use that value if it is valid. Any valid
> domid will be checked against the retired domid list before being passed
> to libxl__domain_make()
flight 146048 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146048/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello,
My recent boot pagetable changes have caused me to work with the EFI
build of Xen rather more than previously.
First, there is a dependency tracking bug in the build system. Edits to
xen/arch/x86/efi/efi-boot.h don't cause xen.efi to be regenerated. From
what I can tell, the file doesn't
As agreed during the 2020-01 community call [1] this patch introduces a
changelog, based on the principles explained at keepachangelog.com [2].
A new MAINTAINERS entry is also added, with myself as (currently sole)
maintainer.
[1] See C.2 at https://cryptpad.fr/pad/#/2/pad/edit/ERZtMYD5j6k0sv-NG6H
On 13.01.2020 16:04, George Dunlap wrote:
> The "nesting" section in the MAINTAINERS file was not initially
> intended to describe the check-in policy for patches, but only how
> nesting worked; but since there was no check-in policy, it has been
> acting as a de-facto policy.
>
> One problem with
On 1/7/20 4:44 PM, Jan Beulich wrote:
> On 07.01.2020 17:17, George Dunlap wrote:
>> On 1/7/20 1:05 PM, Jan Beulich wrote:
>> 2. It must have either a an Acked-by from a maintainer, or a
>>Reviewed-by. This must come from someone other than the submitter.
>
> Better, but leaving ambiguous whe
The "nesting" section in the MAINTAINERS file was not initially
intended to describe the check-in policy for patches, but only how
nesting worked; but since there was no check-in policy, it has been
acting as a de-facto policy.
One problem with this is that the policy is not complete: It doesn't
c
On Mon, 2020-01-13 at 13:01 +, Andrew Cooper wrote:
> On 13/01/2020 11:43, Singh, Balbir wrote:
> > On Mon, 2020-01-13 at 11:16 +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> > > > Hey Peter,
> > > >
> > > > On Wed, Jan 08, 2020 at 11:50:
Hi,
On 13/01/2020 12:51, George Dunlap wrote:
On 1/12/20 6:26 PM, Doug Goldstein wrote:
On 1/11/20 3:02 AM, George Dunlap wrote:
1. Block XENVER_extraversion at the hypervisor level. Change the
xen_deny() string to "". (This is v1 of sergey's patch.)
2. Block XENVER_extraversion at the hype
On 13/01/2020 12:51, George Dunlap wrote:
> On 1/12/20 6:26 PM, Doug Goldstein wrote:
>> On 1/11/20 3:02 AM, George Dunlap wrote:
>>>
On Jan 11, 2020, at 4:02 AM, Doug Goldstein wrote:
On 1/10/20 4:37 AM, Sergey Dyasli wrote:
> Hide the following information that can h
flight 146046 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146046/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 13/01/2020 14:07, George Dunlap wrote:
On 1/13/20 2:01 PM, Andrew Cooper wrote:
On 13/01/2020 13:39, Julien Grall wrote:
Hi George,
Thank you for summarising the possibility. One question below.
On 13/01/2020 12:51, George Dunlap wrote:
2. Block XENVER_extraversion at the hypervisor lev
George Dunlap writes ("Re: [PATCH v2 2/2] libxl: Add new "notify-only"
childproc mode"):
> FAOD, with the fixes in your other series, I consider this patch to now
> be moot.
Right. FTOAD, I don't think there was a problem with this patch
principle; it's just not needed now. If someone comes up
On 1/13/20 2:01 PM, Andrew Cooper wrote:
> On 13/01/2020 13:39, Julien Grall wrote:
>> Hi George,
>>
>> Thank you for summarising the possibility. One question below.
>>
>> On 13/01/2020 12:51, George Dunlap wrote:
>>> 2. Block XENVER_extraversion at the hypervisor level. Leave xen_deny()
>>> as r
On 13/01/2020 13:39, Julien Grall wrote:
> Hi George,
>
> Thank you for summarising the possibility. One question below.
>
> On 13/01/2020 12:51, George Dunlap wrote:
>> 2. Block XENVER_extraversion at the hypervisor level. Leave xen_deny()
>> as returning "", but replace "" with "" in hvmloader s
Doug Goldstein writes ("Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen
version from unprivileged guests"):
> I'd be happy if we had a Kconfig option behind what the string is. Give
> me a blank as an option but default it to whatever string like
> "" that you'd like. Every shipping Xen distro
On Mon, 2020-01-13 at 13:01 +, Andrew Cooper wrote:
> On 13/01/2020 11:43, Singh, Balbir wrote:
> > On Mon, 2020-01-13 at 11:16 +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> > > > Hey Peter,
> > > >
> > > > On Wed, Jan 08, 2020 at 11:50:
On 13.01.2020 14:53, Jan Beulich wrote:
> On 13.01.2020 11:32, Alexandru Stefan ISAILA wrote:
>> On 10.01.2020 18:20, Jan Beulich wrote:
>>> On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
+if ( !(rc = p2m_set_suppress_ve_multi(d, &sve)) && sve.first_error )
+rc = sve.fi
Hi George,
Thank you for summarising the possibility. One question below.
On 13/01/2020 12:51, George Dunlap wrote:
2. Block XENVER_extraversion at the hypervisor level. Leave xen_deny()
as returning "", but replace "" with "" in hvmloader so
it doesn't show up in the System Info and scare use
flight 146044 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146044/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On 13/01/2020 11:43, Singh, Balbir wrote:
> On Mon, 2020-01-13 at 11:16 +0100, Peter Zijlstra wrote:
>> On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
>>> Hey Peter,
>>>
>>> On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
On Tue, Jan 07, 2020 at 11:45:26PM +0
On 13.01.2020 11:32, Alexandru Stefan ISAILA wrote:
> On 10.01.2020 18:20, Jan Beulich wrote:
>> On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
>>> +if ( !(rc = p2m_set_suppress_ve_multi(d, &sve)) && sve.first_error )
>>> +rc = sve.first_error;
>>
>> Why the right side of the && ?
On 1/12/20 6:26 PM, Doug Goldstein wrote:
> On 1/11/20 3:02 AM, George Dunlap wrote:
>>
>>
>>> On Jan 11, 2020, at 4:02 AM, Doug Goldstein wrote:
>>>
>>>
>>>
>>> On 1/10/20 4:37 AM, Sergey Dyasli wrote:
Hide the following information that can help identify the running Xen
binary version:
flight 146045 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146045/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> For your original comment, just wanted to clarify the following:
>
> 1. After hibernation, the machine can be resumed on a different but compatible
> host (these are VM images hibernated)
> 2. This means the clock between host1 and h
On 07/01/2020 16:30, Jan Beulich wrote:
> On 07.01.2020 17:16, Jan Beulich wrote:
>> On 06.01.2020 16:54, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -584,21 +584,24 @@ static void __init efi_arch_memory_setup(void)
>>> if ( !efi_enab
flight 146039 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146039/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 146030
test-amd64-amd64-xl-qemuu-win7-amd64
On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
> When doing a live update, Xen needs to be very careful not to scribble
> on pages which contain guest memory or state information for the
> domains which are being preserved.
>
> The information about which pages are in use is contained i
On Mon, Jan 13, 2020 at 12:43 PM Singh, Balbir wrote:
>
> On Mon, 2020-01-13 at 11:16 +0100, Peter Zijlstra wrote:
> > On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> > > Hey Peter,
> > >
> > > On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> > > > On Tue, Jan
On Mon, 2020-01-13 at 11:16 +0100, Peter Zijlstra wrote:
> On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> > Hey Peter,
> >
> > On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> > > On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> > > > From: Ed
flight 146043 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146043/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 10/01/2020 11:02, Andrew Cooper wrote:
> On 10/01/2020 10:37, Sergey Dyasli wrote:
>> Hide the following information that can help identify the running Xen
>> binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
>> Add explicit cases for XENVER_commandline and XENVER_build
In drm_atomic_helper_fake_vblank(), the DRM core sends out VBLANK
events if struct drm_crtc_state.no_vblank is enabled. Replace cirrus'
VBLANK events with the DRM core's functionality.
v2:
* set struct_drm_crtc_state.no_vblank in cirrus_pipe_check()
Signed-off-by: Thomas Zimmermann
---
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over several drivers.
Ast already uses the functionality and just needs a cleanup. Cirrus can
be converted easil
In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
For drivers that have neither an enable_vblank() callback nor a check()
callback, the simple-KMS helpers enable VBLANK generation by default. This
simplif
CRTC state properties should be computed in atomic_check(). Do so for
the no_vblank field.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
i
Drivers for CRTC hardware without support for VBLANK interrupts can set
struct drm_crtc_state.no_vblank and let DRM's atomic commit helpers
generate the VBLANK events automatically. Document this in order to make
it official.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_atomic_helper
I did not find anything in the Xen 4.13 release notes, so I'm asking here:
This HVM domU fails to live migrate from staging-4.12 to staging-4.13:
name='hvm'
serial='pty'
vcpus='4'
memory='888'
disk=[ 'vdev=xvda, format=raw, access=rw, target=/netshare/disk0.raw' ]
vif=[ 'bridge=br0,mac=3c:27:63:5
On 10.01.2020 18:20, Jan Beulich wrote:
> On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
>> By default the sve bits are not set.
>> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
>> to set a range of sve bits.
>> The core function, p2m_set_suppress_ve_multi(), does not br
On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> Hey Peter,
>
> On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> > > From: Eduardo Valentin
> > >
> > > System instability are seen during resum
flight 146041 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On Mon, 13 Jan 2020 10:55:07 +0100 "Roger Pau Monné"
wrote:
> On Mon, Jan 13, 2020 at 10:49:52AM +0100, SeongJae Park wrote:
> > Every patch of this patchset got at least one 'Reviewed-by' or 'Acked-by'
> > from
> > appropriate maintainers by last Wednesday, and after that, got no comment
> >
On Mon, Jan 13, 2020 at 10:49:52AM +0100, SeongJae Park wrote:
> Every patch of this patchset got at least one 'Reviewed-by' or 'Acked-by' from
> appropriate maintainers by last Wednesday, and after that, got no comment yet.
> May I ask some more comments?
I'm not sure why more comments are needed
Every patch of this patchset got at least one 'Reviewed-by' or 'Acked-by' from
appropriate maintainers by last Wednesday, and after that, got no comment yet.
May I ask some more comments?
Thanks,
SeongJae Park
On Wed, 18 Dec 2019 19:37:13 +0100 SeongJae Park wrote:
> Granting pages consumes ba
flight 146042 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
13.01.2020 11:57, Paul Durrant wrote:
> On Fri, 10 Jan 2020 at 19:42, Vladimir Sementsov-Ogievskiy
> wrote:
>>
>> If we want to add some info to errp (by error_prepend() or
>> error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
>> Otherwise, this info will not be added when errp == &e
13.01.2020 11:50, Paul Durrant wrote:
> On Fri, 10 Jan 2020 at 19:42, Vladimir Sementsov-Ogievskiy
> wrote:
> [snip]
>> +/*
>> + * ERRP_AUTO_PROPAGATE
>> + *
>> + * This macro is created to be the first line of a function which use
>> + * Error **errp parameter to report error. It's needed only in
On Fri, 10 Jan 2020 at 19:42, Vladimir Sementsov-Ogievskiy
wrote:
>
> If we want to add some info to errp (by error_prepend() or
> error_append_hint()), we must use the ERRP_AUTO_PROPAGATE macro.
> Otherwise, this info will not be added when errp == &error_fatal
> (the program will exit prior to t
On Fri, 10 Jan 2020 at 19:42, Vladimir Sementsov-Ogievskiy
wrote:
[snip]
> +/*
> + * ERRP_AUTO_PROPAGATE
> + *
> + * This macro is created to be the first line of a function which use
> + * Error **errp parameter to report error. It's needed only in cases where we
> + * want to use error_prepend,
100 matches
Mail list logo
