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
>>
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
> -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...
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
flight 150591 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150591/
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
> -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
> ;
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
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.
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.
>
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 ;
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
>
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 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
> -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
> -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
> -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;
+ 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
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
> -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]
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
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
> -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
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
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
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
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
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
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
> 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
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,
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
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:
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
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
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
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
> 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
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
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
+++
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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 ;
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:
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
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
---
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
---
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
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
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
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
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
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
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
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
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
>
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
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.
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
> 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
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
>
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
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,
> +
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
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
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
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é
> ---
> target/i386/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard
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
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
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
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:
>
>
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:
>
> $
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 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
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
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
91 matches
Mail list logo
