flight 150592 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
> -Original Message-
> From: Philippe Mathieu-Daudé On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 31 May 2020 18:38
> To: qemu-de...@nongnu.org
> Cc: Andrew Jeffery ; Helge Deller ; Peter
> Maydell
> ; Richard Henderson ; Eduardo
> Habkost
> ; Paul Durrant ; Hervé Poussineau
> ; Marcel
> -Original Message-
> From: Andrew Cooper On Behalf Of Andrew Cooper
> Sent: 30 May 2020 01:30
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Ian Jackson
> ; Wei Liu
> Subject: Re: [PATCH v6 5/5] tools/libxc: make use of domain context
> SHARED_INFO record...
On 6/1/20 9:26 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Philippe Mathieu-Daudé On Behalf Of
>> Philippe Mathieu-Daudé
>> Sent: 31 May 2020 18:38
>> To: qemu-de...@nongnu.org
>> Cc: Andrew Jeffery ; Helge Deller ; Peter
>> Maydell
>> ; Richard Henderson ; Eduardo
>> Habkost
On Fri, May 29, 2020 at 05:45:44PM +0200, Jan Beulich wrote:
> On 28.05.2020 16:40, Roger Pau Monne wrote:
> > LLVM linker doesn't support discarding .shstrtab, and complains with:
> >
> > ld -melf_i386_fbsd -N -T build32.lds -o reloc.lnk reloc.o
> > ld: error: discarding .shstrtab section is not
On Fri, May 29, 2020 at 10:11:40AM -0700, Andy Lutomirski wrote:
> > On May 29, 2020, at 4:30 AM, Daniel Kiper wrote:
> >
> > Hey,
> >
> > Below you can find my rough idea of the bootloader log format which is
> > generic thing but initially will be used for TrenchBoot work. I discussed
> > this p
flight 150594 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150594/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
On Fri, May 29, 2020 at 01:27:35PM +0200, Daniel Kiper wrote:
> Hey,
>
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I discussed
> this proposal with Ross and Daniel S. So, the idea went through initial
> sa
On 6/1/20 10:33 AM, Philippe Mathieu-Daudé wrote:
> On 6/1/20 9:26 AM, Paul Durrant wrote:
>>> -Original Message-
>>> From: Philippe Mathieu-Daudé On Behalf
>>> Of Philippe Mathieu-Daudé
>>> Sent: 31 May 2020 18:38
>>> To: qemu-de...@nongnu.org
>>> Cc: Andrew Jeffery ; Helge Deller ; Pete
flight 150589 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150589/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 150551 pass in 150589
test-amd64-coresched-i386-xl 16
On Thu, May 28, 2020 at 11:34 AM Tian, Kevin wrote:
> You may search dma_map* in drivers/gpu/drm/i915, and then print mapped
> addresses to see any match in VT-d reported faulting addresses. For
> example, __setup_page_dma might be one example that you want to check.
>
Unfortunately, I'm not rea
If a Xen build fails, but we are trying to bisect something involving
libvirt, the libvirt job does not really run. It does not populate
the tree_ values for its git submodules - that would involve
actually booking out a host and cloning it.
The effect is that xen build failures which occur somew
This query is going to turn into two variants, one of which doesn't
have the url join.
In the output, prefer to refer to fields from job. They are
constrained to be equal (and they are not null) so this has no
functional change.
Also swap the conditions over for clarity.
No functional change.
Break out various pieces that we are going to need to reuse for the
other version of this query (which won't have the url join).
Also, rather than retrieving the `tree_' runvar and calculating
the tree name from that, use the `[built_]revision_' runvar from
rev.
No overall functional change.
Sig
This variant just returns '' for urls. Unlike the with-urls variant,
it does not ignore trees without urls.
Signed-off-by: Ian Jackson
---
cs-bisection-step | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/cs-bisection-step b/cs-bisection-step
index b36bac
> On May 29, 2020, at 6:24 PM, Julien Grall wrote:
>
> Hi Jan,
>
> On 29/05/2020 16:11, Jan Beulich wrote:
>> On 29.05.2020 17:05, Julien Grall wrote:
>>> On 29/05/2020 15:47, Ian Jackson wrote:
George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> Which isn’t to s
Hi George,
On 01/06/2020 13:57, George Dunlap wrote:
On May 29, 2020, at 6:24 PM, Julien Grall wrote:
Hi Jan,
On 29/05/2020 16:11, Jan Beulich wrote:
On 29.05.2020 17:05, Julien Grall wrote:
On 29/05/2020 15:47, Ian Jackson wrote:
George Dunlap writes ("Re: Xen XSM/FLASK policy, grub de
To Whom it May Concern:
Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux
4.19.59. It has a 32-bit ARM Cortex A15 processor. There is keystone
specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes
during early_paging_init for LPAE support. This causes the
We can skip a bunch of steps a normal domain creation would entail, similar
to how domain restore & soft_reset skips them.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_create.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libx
Skips parts not relevant for VM forks. No functional change in existing code,
only relocating some bits that don't need to be done at the very end.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_dom.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --gi
Skips parts not relevant to VM forks.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_dom.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 1b55097a1a..52d49437cc 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom
Add special handling when only the the device model needs launching for forks.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_create.c | 9 +
tools/libxl/libxl_internal.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.
No need to call libxl__domain_make since the domain already exists, only need
to populate the xenstore entries via libxl__domain_make_xs_entries.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_create.c | 11 ++-
tools/libxl/libxl_types.idl | 1 +
2 files changed, 11 insertions(+)
The following patches are part of the series that implement VM forking for
Intel HVM guests to allow for the fast creation of identical VMs without the
assosciated high startup costs of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The for
Toolstack side for creating forks with interrupt injection blocked.
Signed-off-by: Tamas K Lengyel
Reviewed-by: Roger Pau Monné
Acked-by: Ian Jackson
---
tools/libxc/include/xenctrl.h | 3 ++-
tools/libxc/xc_memshr.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git
And make sure we don't remove the file once done.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_create.c | 4
tools/libxl/libxl_dm.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab3ac096ee..27f
Signed-off-by: Tamas K Lengyel
---
docs/man/xl.1.pod.in | 39 +++
1 file changed, 39 insertions(+)
diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..9e87b0314f 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708
Adding the xl fork-vm command, compiled only on x86. Only the essential bits
are available via this command to create a fork and launch QEMU for it. The
command still allows to perform the task in a split-model, first creating the
fork and launching QEMU only later.
Signed-off-by: Tamas K Lengyel
Add libxl__build_hvm_fork function that performs only the steps needed for VM
forks, skipping a large chunk of libxl__build_hvm.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_dom.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/tools/
When running VM forks without device models (QEMU), it may
be undesirable for Xen to inject interrupts. When creating such forks from
Windows VMs we have observed the kernel trying to process interrupts
immediately after the fork is executed. However without QEMU running such
interrupt handling may
Make part of libxl__domain_make into a separate function. No functional change.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_create.c | 62 +++-
tools/libxl/libxl_internal.h | 4 ++-
2 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/tools
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl.h| 10 +
tools/libxl/libxl_create.c | 44 ++
2 files changed, 54 insertions(+)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..79792d6e29 100644
--- a/tools/libxl/lib
Hello,
I have a few questions in order to understand a bit more your problem.
On 01/06/2020 13:38, CodeWiz2280 wrote:
Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux
4.19.59. It has a 32-bit ARM Cortex A15 processor. There is keystone
specific code in the kernel in ar
> On Jun 1, 2020, at 2:10 PM, Julien Grall wrote:
> 4. Extract the .config from the binary using a similar script to
> script/extract-ikconfig.
Ah, gotcha. I did misunderstand your suggestion.
-George
Extend the disclaimer about runtime loading. While we've done our best to
make the mechaism reliable, the safety of late loading does ultimately depend
on the contents of the blobs.
Extend the xen-ucode portion with examples of how to use it.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
LLVM linker doesn't support discarding .shstrtab, and complains with:
ld -melf_i386_fbsd -N -T build32.lds -o reloc.lnk reloc.o
ld: error: discarding .shstrtab section is not allowed
Add an explicit .shstrtab, .strtab and .symtab sections to the linker
script after the text section in order to ma
Hello,
Two pending bug fixes for clang/llvm toolstacks.
Roger Pau Monne (2):
x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean
build32: don't discard .shstrtab in linker script
xen/arch/x86/boot/build32.lds | 14 ++
xen/arch/x86/mm.c | 9 -
2 files
Clang 10 complains with:
mm.c:1239:10: error: converting the result of '<<' to a boolean always
evaluates to true
[-Werror,-Wtautological-constant-compare]
if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
^
xen/include/asm/x86_64/page.h:161:25: note: expanded from ma
On 01/06/2020 14:35, George Dunlap wrote:
On Jun 1, 2020, at 2:10 PM, Julien Grall wrote:
4. Extract the .config from the binary using a similar script to
script/extract-ikconfig.
Ah, gotcha. I did misunderstand your suggestion.
The advantage I can see with this solution is this is arc
George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> The options proposed have included:
Thanks for summarising!
> 1. Making the tools not generate a FLASK policy unless FLASK is enabled in
> the hypervisor being built. This is flaky because there’s no necessary
> connecti
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci/pci_bridge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index 3ba3203f72..3789c17edc 100
memory_region_set_size() handle the 16 Exabytes limit by
special-casing the UINT64_MAX value. This is not a problem
for the 32-bit maximum, 4 GiB.
By using the UINT32_MAX value, the aspeed-ram-container
MemoryRegion ends up missing 1 byte:
$ qemu-system-arm -M ast2600-evb -S -monitor stdio
(qemu
Series fully reviewed.
Since v1:
- Add parenthesis on the Xen patch (Paul Durrant)
- Add Peter's R-b tags
memory_region_set_size() handle the 16 Exabytes limit by
special-casing the UINT64_MAX value.
This is not a problem for the 32-bit maximum, 4 GiB, but
in some places we incorrectly use UINT32
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/i440fx.c| 3 ++-
hw/pci-host/q35.c | 2 +-
hw/pci-host/versatile.c | 5 +++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/
memory_region_set_size() handle the 16 Exabytes limit by
special-casing the UINT64_MAX value. This is not a problem
for the 32-bit maximum, 4 GiB.
By using the UINT32_MAX value, the pci_bridge_io MemoryRegion
ends up missing 1 byte:
(qemu) info mtree
memory-region: pci_bridge_io
00
memory_region_set_size() handle the 16 Exabytes limit by
special-casing the UINT64_MAX value. This is not a problem
for the 32-bit maximum, 4 GiB.
By using the UINT32_MAX value, the bm-raven MemoryRegion
ends up missing 1 byte:
$ qemu-system-ppc -M prep -S -monitor stdio -usb
memory-region: bm
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 82ece6b9e7..94fe5d65e9
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3733d9a279..33ce4861fb 100644
--- a/
IEC binary prefixes ease code review: the unit is explicit.
Reviewed-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
---
hw/hppa/dino.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hppa/dino.c b/hw/hppa/dino.c
index 2b1b38c58a..7290f23962 100644
--- a/hw/hp
flight 150596 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150596/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops hooks"
identified several poor behaviours of the start_update()/end_update_percpu()
hooks.
AMD have subsequently confirmed that OSVW don't, and are not expected to,
change across a microcode load, rendering all of this complexit
> -Original Message-
> From: Xen-devel On Behalf Of Tamas K
> Lengyel
> Sent: 01 June 2020 14:22
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Tamas K Lengyel
> ; Jun Nakajima ; Wei Liu
> ; Andrew Cooper
> ; Ian Jackson ; George
> Dunlap
> ; Tamas K Len
> -Original Message-
> From: Andrew Cooper
> Sent: 01 June 2020 14:40
> To: Xen-devel
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Jan Beulich ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu ; Julien
> Grall ; Paul Durrant
> Subject: [PATCH for-4.14] docs/ucode
Hi Julien,
Thank you for your response. I will try and post a log for you. I have
been switching back and forth between configurations and need to take a new
one.
The board has 4GB of memory. Uboot places the kernel/initramfs/dtb in the
0x8000_ region but then the kernel switches its code/d
> -Original Message-
> From: Roger Pau Monne
> Sent: 01 June 2020 14:53
> To: xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Roger Pau Monne ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu
> Subject: [PATCH v3 0/2] clang/llvm: build fixes
>
> Hello,
>
> Two pending bug fixes for clang/
> -Original Message-
> From: Philippe Mathieu-Daudé On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 01 June 2020 15:29
> To: qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; Anthony Perard
> ; Paolo Bonzini
> ; Hervé Poussineau ; Helge Deller
> ; qemu-
> a...@nongnu.org; Marcel
> -Original Message-
> From: Andrew Cooper
> Sent: 01 June 2020 15:58
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ;
> Roger Pau Monné ; Paul Durrant
> Subject: [PATCH for-4.14] x86/ucode: Fix errors with start/end_update()
>
> c/s 9267a439c "x86/ucode: Document the be
On Mon, Jun 01, 2020 at 03:57:55PM +0100, Andrew Cooper wrote:
> c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops hooks"
> identified several poor behaviours of the start_update()/end_update_percpu()
> hooks.
>
> AMD have subsequently confirmed that OSVW don't, and are not exp
On 01/06/2020 16:48, Roger Pau Monné wrote:
> On Mon, Jun 01, 2020 at 03:57:55PM +0100, Andrew Cooper wrote:
>> c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops hooks"
>> identified several poor behaviours of the start_update()/end_update_percpu()
>> hooks.
>>
>> AMD have subse
ping
On 5/20/20 12:04 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hello all,
>
> this series extends the existing displif protocol with new
> request and adds additional parameter to the exiting one.
> It also provides support for the new parameter in libgnttab
> via io
On 6/1/20 4:29 PM, Philippe Mathieu-Daudé wrote:
> memory_region_set_size() handle the 16 Exabytes limit by
> special-casing the UINT64_MAX value. This is not a problem
> for the 32-bit maximum, 4 GiB.
> By using the UINT32_MAX value, the aspeed-ram-container
> MemoryRegion ends up missing 1 byte:
+ George
On Sun, 31 May 2020, Roman Shaposhnik wrote:
> Hi Julien!
>
> On Sun, May 31, 2020 at 3:24 PM Julien Grall
> wrote:
> >
> > On Sun, 31 May 2020 at 23:05, Roman Shaposhnik wrote:
> > > Hi!
> > >
> > > with a lot of help from Stefano, we're getting RPi4 support in
> > > Project EVE pret
On Mon, Jun 01, 2020 at 02:40:25PM +0100, Andrew Cooper wrote:
> Extend the disclaimer about runtime loading. While we've done our best to
> make the mechaism reliable, the safety of late loading does ultimately depend
> on the contents of the blobs.
>
> Extend the xen-ucode portion with examp
> On Jun 1, 2020, at 4:07 PM, Paul Durrant wrote:
>
>> -Original Message-
>> From: Xen-devel On Behalf Of Tamas
>> K Lengyel
>> Sent: 01 June 2020 14:22
>> To: xen-devel@lists.xenproject.org
>> Cc: Kevin Tian ; Stefano Stabellini
>> ; Tamas K Lengyel
>> ; Jun Nakajima ; Wei Liu
>> ;
On 01/06/2020 17:51, Roger Pau Monné wrote:
>
> On Mon, Jun 01, 2020 at 02:40:25PM +0100, Andrew Cooper wrote:
>> Extend the disclaimer about runtime loading. While we've done our best to
>> make the mechaism reliable, the safety of late loading does ultimately depend
>> on the contents of the blo
flight 150598 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150598/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
Hi Julien,
As requested please see log below from the eval board booting dom0, some
notes are as follows:
1. The offset that gets applied to the 32-bit address to translate it
to 36-bits is 0x7_8000_
2. Uboot has been setup to not change the address of the memory in the
device tree prior to l
On Mon, Jun 1, 2020 at 11:11 AM George Dunlap wrote:
>
>
>
> > On Jun 1, 2020, at 4:07 PM, Paul Durrant wrote:
> >
> >> -Original Message-
> >> From: Xen-devel On Behalf Of
> >> Tamas K Lengyel
> >> Sent: 01 June 2020 14:22
> >> To: xen-devel@lists.xenproject.org
> >> Cc: Kevin Tian ; S
On Wed, May 20, 2020 at 8:31 PM Tamas K Lengyel wrote:
>
> For the last couple years we have received numerous reports from users of
> monitor vm_events of spurious guest crashes when using events. In particular,
> it has observed that the problem occurs when vm_events are being disabled. The
> na
flight 150590 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150590/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 150556
Tests which did not succeed,
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> Many legacy device drivers do not implement power management (PM)
flight 150605 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150605/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
On 5/19/20 7:24 PM, Anchal Agarwal wrote:
>
> +enum suspend_modes {
> + NO_SUSPEND = 0,
> +
n Fri, 22 May 2020, Dominique Martinet wrote:
> Stefano Stabellini wrote on Thu, May 21, 2020:
> > From: Stefano Stabellini
> >
> > Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the
> > max allowed by the protocol.
> >
> > We can't assume that all backends will support ord
flight 150593 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150593/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150585
test-amd64-i386-xl-qemuu-win7-amd64
On 6/1/20 5:00 PM, Agarwal, Anchal wrote:
>
>
> I don't see these last two used anywhere. Are you, in fact,
> distinguishing between PM suspend and hibernation?
>
> Yes, I am. Unless there is a better way to distinguish at runtime which I
> haven't figured out yet.
> The initial desig
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> memory_region_set_size() handle the 16 Exabytes limit by
> special-casing the UINT64_MAX value. This is not a problem
> for the 32-bit maximum, 4 GiB.
> By using the UINT32_MAX value, the aspeed-ram-container
> MemoryRegion ends up missing 1 byte:
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> memory_region_set_size() handle the 16 Exabytes limit by
> special-casing the UINT64_MAX value. This is not a problem
> for the 32-bit maximum, 4 GiB.
> By using the UINT32_MAX value, the bm-raven MemoryRegion
> ends up missing 1 byte:
>
> $ qem
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> memory_region_set_size() handle the 16 Exabytes limit by
> special-casing the UINT64_MAX value. This is not a problem
> for the 32-bit maximum, 4 GiB.
> By using the UINT32_MAX value, the pci_bridge_io MemoryRegion
> ends up missing 1 byte:
>
>
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
On 5/19/20 7:25 PM, Anchal Agarwal wrote:
>
> int xenbus_dev_resume(struct device *dev)
> {
> -
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> IEC binary prefixes ease code review: the unit is explicit.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/pci-host/i440fx.c| 3 ++-
> hw/pci-host/q35.c | 2 +-
> hw/pci-host/versatile.c | 5 +++--
>
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> IEC binary prefixes ease code review: the unit is explicit.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/pci/pci_bridge.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Richard Hen
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> IEC binary prefixes ease code review: the unit is explicit.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/i386/xen/xen-hvm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Richard Hen
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> IEC binary prefixes ease code review: the unit is explicit.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/hppa/dino.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Richard Henderso
On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote:
> IEC binary prefixes ease code review: the unit is explicit.
>
> Reviewed-by: Peter Maydell
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> target/i386/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
On Fri, 2020-05-29 at 10:48 +0200, Dario Faggioli wrote:
> On Tue, 2020-05-26 at 02:27 +, Volodymyr Babchuk wrote:
> > Hello All,
> >
> Hello Volodymyr,
>
Hi Dario,
> > This is gentle reminder about this RFC.
> >
> > Sadly, Andrii Anisov has left our team. But I'm commited to continue
> >
On Mon, Jun 01, 2020 at 04:29:22PM +0200, Philippe Mathieu-Daudé wrote:
> Series fully reviewed.
>
> Since v1:
> - Add parenthesis on the Xen patch (Paul Durrant)
> - Add Peter's R-b tags
PCI things:
Reviewed-by: Michael S. Tsirkin
I'll queue pci patches in my tree.
> memory_region_set_size
On Fri, 29 May 2020 13:27:35 +0200
Daniel Kiper wrote:
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I
> discussed this proposal with Ross and Daniel S. So, the idea went
> through initial sanitization. Now
flight 150606 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150606/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 15 guest-saverestorefail REGR. vs. 150590
Tests which did not succeed,
On Fri, May 29, 2020 at 09:39:53AM +0200, Gerd Hoffmann wrote:
> With more microvm memory config tweaks split this into its owns series,
> the microvm acpi patch series is already big enough ...
Okay.
We might want to add pci to microvm and maybe we'll need more space
then, but let's leave this f
Juergen Gross (2):
tools: check return value of asprintf() in xenhypfs
tools: make libxenhypfs interface more future proof
tools/libs/hypfs/core.c | 2 +-
tools/libs/hypfs/include/xenhypfs.h | 31 +
tools/misc/xenhypfs.c | 10 --
asprintf() can fail, so check its return value. Additionally fix a
memory leak in xenhypfs.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
tools/misc/xenhypfs.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/misc/xenhypfs.c b/tools/misc/xenhypfs.c
i
Stefano Stabellini wrote on Mon, Jun 01, 2020:
> > LGTM, I'll try to find some time to test this by the end of next week or
> > will trust you if I can't make it -- ping me around June 1st if I don't
> > reply again until then...
>
> Ping :-)
I actually did think about this patch this weekend! .
As compilers are free to choose the width of an enum they should be
avoided in stable interfaces when declaring a variable. So the
struct xenhypfs_dirent definition should be modified to have explicitly
sized members for type and encoding and the related enums should be
defined separately.
Additio
flight 150612 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
95 matches
Mail list logo
