flight 149455 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149455/
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: Julien Grall
> Sent: 04 April 2020 14:10
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
> ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Wei Liu ; Roger Pau Monné
> ;
> -Original Message-
> From: Xen-devel On Behalf Of Dongli
> Zhang
> Sent: 03 April 2020 23:33
> To: Andrew Cooper ; Anastassios Nanos
> ; xen-
> de...@lists.xen.org
> Subject: Re: Live migration and PV device handling
>
> Hi Andrew,
>
> On 4/3/20 5:42 AM, Andrew Cooper wrote:
> > On 0
flight 149447 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149447/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
144861
test-amd6
Without it Linux is not able to parse the x2APIC ACPI MADT entries
crafted by Xen when booted in PVH mode, following log is from one of
the dom0pvh jobs:
ACPI: x2apic entry ignored
ACPI: x2apic entry ignored
ACPI: x2apic entry ignored
ACPI: x2apic entry ignored
IOAPIC[0]: apic_id 0, version 17, ad
Since Xen 4.4 the maximum number of event channels for a guest is
defaulting to 1023. For large guests with lots of vcpus this is not
enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
limiting the guest to about 140 vcpus.
Instead of requiring to specify the allowed number of event
> -Original Message-
> From: Julien Grall
> Sent: 03 April 2020 18:24
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' ; 'George Dunlap'
> ; 'Ian
> Jackson' ; 'Jan Beulich' ;
> 'Stefano Stabellini'
> ; 'Wei Liu'
> Subject: Re: [PATCH 1/5] xen/common: introduce a
Ping.
On Mon, 2020-03-23 at 09:41 +, Hongyan Xia wrote:
> From: Hongyan Xia
>
> This small series is basically just rewriting functions using the new
> API to map and unmap PTEs. Each patch is independent.
>
> Apart from mapping and unmapping page tables, no other functional
> change
> inte
On Thu, 2020-04-02 at 18:32 +, George Dunlap wrote:
> > On Mar 19, 2020, at 12:12 AM, Dario Faggioli
> > wrote:
> >
> > There is a bug in commit 5e4b4199667b9 ("xen: credit2: only reset
> > credit on reset condition"). In fact, the aim of that commit was to
> > make sure that we do not perfor
Hi Paul,
On 06/04/2020 08:40, Paul Durrant wrote:
diff --git a/xen/include/asm-x86/guest_access.h
b/xen/include/asm-x86/guest_access.h
index 9ee275d01f..5c3dfc47b6 100644
--- a/xen/include/asm-x86/guest_access.h
+++ b/xen/include/asm-x86/guest_access.h
@@ -54,22 +54,24 @@
/* Cast a XEN_GUEST
On Fri, Apr 03, 2020 at 11:00:34AM +0200, Juergen Gross wrote:
> Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for
> large array allocation") didn't fix the issue it was meant to, as the
> flags for allocating the memory are GFP_NOIO, which will lead the
> memory allocation fallin
> -Original Message-
> From: Julien Grall
> Sent: 01 April 2020 14:42
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Daniel De Graaf ; Ian Jackson
> ; Wei Liu
> ; Andrew Cooper ; George Dunlap
> ; Jan
> Beulich ; Stefano Stabellini
> Subject: Re: [PATCH 2/5] xen/common/domctl
Hi Paul,
On 06/04/2020 09:27, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 03 April 2020 18:24
To: p...@xen.org; xen-devel@lists.xenproject.org
Cc: 'Andrew Cooper' ; 'George Dunlap'
; 'Ian
Jackson' ; 'Jan Beulich' ;
'Stefano Stabellini'
; 'Wei Liu'
Subject: Re: [PA
> -Original Message-
> From: Julien Grall
> Sent: 06 April 2020 10:08
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' ; 'George Dunlap'
> ; 'Ian
> Jackson' ; 'Jan Beulich' ;
> 'Stefano Stabellini'
> ; 'Wei Liu'
> Subject: Re: [PATCH 1/5] xen/common: introduce a
Hi Jurgen,
On 06/04/2020 09:27, Juergen Gross wrote:
Since Xen 4.4 the maximum number of event channels for a guest is
defaulting to 1023. For large guests with lots of vcpus this is not
enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
limiting the guest to about 140 vcpus.
Lar
Hi Paul,
On 06/04/2020 10:18, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 06 April 2020 10:08
To: p...@xen.org; xen-devel@lists.xenproject.org
Cc: 'Andrew Cooper' ; 'George Dunlap'
; 'Ian
Jackson' ; 'Jan Beulich' ;
'Stefano Stabellini'
; 'Wei Liu'
Subject: Re: [PA
On 06.04.20 11:24, Julien Grall wrote:
Hi Jurgen,
On 06/04/2020 09:27, Juergen Gross wrote:
Since Xen 4.4 the maximum number of event channels for a guest is
defaulting to 1023. For large guests with lots of vcpus this is not
enough, as e.g. the Linux kernel uses 7 event channels per vcpu,
limi
> -Original Message-
[snip]
> >> * The name of the hypercall does not say anything about "PV". So a
> >> contributor could think it would be fine to save/restore new HVM state
> >> in the new generic hypercall. Is it going to be an issue? If so, how do
> >> we prevent it?
> >
> > The co
Hi Juergen,
On 06/04/2020 11:17, Jürgen Groß wrote:
On 06.04.20 11:24, Julien Grall wrote:
Hi Jurgen,
On 06/04/2020 09:27, Juergen Gross wrote:
Since Xen 4.4 the maximum number of event channels for a guest is
defaulting to 1023. For large guests with lots of vcpus this is not
enough, as e.g.
Roger Pau Monne writes ("[PATCH OSSTEST] linux: enable x2APIC kernel support"):
> Without it Linux is not able to parse the x2APIC ACPI MADT entries
> crafted by Xen when booted in PVH mode, following log is from one of
> the dom0pvh jobs:
Acked-by: Ian Jackson
And pushed to pretest.
Thanks,
Ia
Jürgen Groß writes ("Re: [PATCH v2] tools/libxl: make default of max event
channels dependant on vcpus"):
> On 06.04.20 11:24, Julien Grall wrote:
> > Large guests on which arch? Which type of guests?
>
> I'm pretty sure this applies to x86 only. I'm not aware of event
> channels being used on AR
On 06.04.20 12:37, Julien Grall wrote:
Hi Juergen,
On 06/04/2020 11:17, Jürgen Groß wrote:
On 06.04.20 11:24, Julien Grall wrote:
Hi Jurgen,
On 06/04/2020 09:27, Juergen Gross wrote:
Since Xen 4.4 the maximum number of event channels for a guest is
defaulting to 1023. For large guests with l
On Mon, Mar 30, 2020 at 08:02:08AM -0700, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and
> a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to be functional the VM state is copied over as part
Jürgen Groß writes ("Re: [PATCH v2] tools/libxl: make default of max event
channels dependant on vcpus"):
> Okay, what about moving the default setting of b_info->event_channels
> into libxl__arch_domain_build_info_setdefault() then?
FTAOD, if this satisfies ARM maintainers then I am content with
Hi Ian,
On 06/04/2020 11:47, Ian Jackson wrote:
Jürgen Groß writes ("Re: [PATCH v2] tools/libxl: make default of max event channels
dependant on vcpus"):
On 06.04.20 11:24, Julien Grall wrote:
Large guests on which arch? Which type of guests?
I'm pretty sure this applies to x86 only. I'm no
Hello,
This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.
Thanks, Roger.
Roger Pau Monne (3):
x86/tlb: introduce a flush HVM ASIDs flag
x86/tlb: allow disabling the TLB clock
x86/tlb: use X
Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't req
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
On Thu, Apr 02, 2020 at 03:27:22PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD
> > Sent: 02 April 2020 14:08
> > To: qemu-de...@nongnu.org
> > Cc: qemu-sta...@nongnu.org; Anthony PERARD ;
> > Stefano Stabellini
> > ; Paul Durrant ; Stefan Hajnoczi
> > ; Kev
Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event
channels dependant on vcpus"):
> There are no correlation between event channels and vCPUs. The number of
> event channels only depends on the number of frontend you have in your
> guest. So...
>
> Hi Ian,
>
> On 06/04
On 04.04.2020 15:06, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
> data to guest handle marked const.
>
> Thankfully, no users of the helper will do that. Rather than hoping this
> can be caught during review, harden copy_
On 06.04.20 13:00, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels
dependant on vcpus"):
There are no correlation between event channels and vCPUs. The number of
event channels only depends on the number of frontend you have in your
guest.
On 06.04.2020 10:27, Hongyan Xia wrote:
> Ping.
Does this somehow imply you didn't get my replies sent on the 1st?
Jan
> On Mon, 2020-03-23 at 09:41 +, Hongyan Xia wrote:
>> From: Hongyan Xia
>>
>> This small series is basically just rewriting functions using the new
>> API to map and unmap
On 06.04.2020 13:00, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event
> channels dependant on vcpus"):
>> There are no correlation between event channels and vCPUs. The number of
>> event channels only depends on the number of frontend you have in y
flight 149451 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149451/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 149406
test-armhf-armhf-libvirt 14 save
On 19.03.2020 01:12, Dario Faggioli wrote:
> @@ -3328,12 +3325,9 @@ runq_candidate(struct csched2_runqueue_data *rqd,
> (unsigned char *)&d);
> }
>
> -/* Only consider units that are allowed to run on this processor. */
> +/* Only consider vcpus t
On 06.04.20 13:11, Jan Beulich wrote:
On 06.04.2020 13:00, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels
dependant on vcpus"):
There are no correlation between event channels and vCPUs. The number of
event channels only depends on the n
On 06/04/2020 08:50, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Dongli
>> Zhang
>> Sent: 03 April 2020 23:33
>> To: Andrew Cooper ; Anastassios Nanos
>> ; xen-
>> de...@lists.xen.org
>> Subject: Re: Live migration and PV device handling
>>
>> Hi Andrew,
>>
Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
remove") revealed that a request was removed twice from a list, once
in xen_block_finish_request() and a second time in
xen_block_release_request() when both function are called from
xen_block_complete_aio(). But also, the `requests_
On Mon, Apr 6, 2020 at 4:52 AM Roger Pau Monné wrote:
>
> On Mon, Mar 30, 2020 at 08:02:08AM -0700, Tamas K Lengyel wrote:
> > VM forking is the process of creating a domain with an empty memory space
> > and a
> > parent domain specified from which to populate the memory when necessary.
> > For
> -Original Message-
> From: Anthony PERARD
> Sent: 06 April 2020 15:02
> To: qemu-de...@nongnu.org
> Cc: qemu-sta...@nongnu.org; Anthony PERARD ;
> Stefano Stabellini
> ; Paul Durrant ; Stefan Hajnoczi
> ; Kevin
> Wolf ; Max Reitz ;
> xen-devel@lists.xenproject.org; qemu-
> bl...@nongn
The following series implements 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 fork operation is implemented a
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
doc
Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show abou
VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).
Signed-off-by:
Since 7f5d9b206d1e ("object-add: don't create return value if
failed"), qmp_object_add() don't write any value in 'ret_data', thus
has random data. Then qobject_unref() fails and abort().
Fix by initialising 'ret_data' properly.
Fixes: 5f07c4d60d09 ("qapi: Flatten object-add")
Signed-off-by: Anth
On 4/6/20 6:42 PM, Anthony PERARD wrote:
Since 7f5d9b206d1e ("object-add: don't create return value if
failed"), qmp_object_add() don't write any value in 'ret_data', thus
has random data. Then qobject_unref() fails and abort().
Fix by initialising 'ret_data' properly.
Or move qobject_unref()
On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper wrote:
>
> On 03/04/2020 13:32, Anastassios Nanos wrote:
> > Hi all,
> >
> > I am trying to understand how live-migration happens in xen. I am
> > looking in the HVM guest case and I have dug into the relevant parts
> > of the toolstack and the hypervis
On Mon, Apr 06, 2020 at 06:50:41PM +0200, Philippe Mathieu-Daudé wrote:
> On 4/6/20 6:42 PM, Anthony PERARD wrote:
> > Since 7f5d9b206d1e ("object-add: don't create return value if
> > failed"), qmp_object_add() don't write any value in 'ret_data', thus
> > has random data. Then qobject_unref() fai
On 06/04/2020 18:16, Tamas K Lengyel wrote:
> On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper
> wrote:
>> On 03/04/2020 13:32, Anastassios Nanos wrote:
>>> Hi all,
>>>
>>> I am trying to understand how live-migration happens in xen. I am
>>> looking in the HVM guest case and I have dug into the rele
flight 149452 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-i386-xl-qemuu-debianhvm-amd6
On 04.04.2020 12:26, Julien Grall wrote:
> From: Julien Grall
>
> Since commit 9facd54a45 "x86/ioapic: Add register level checks to detect
> bogus io-apic entries", Xen is able to cope with IO APICs not mapped in
> the fixmap.
>
> Therefore the whole logic to allocate a fake page for some IO API
On 06.04.2020 11:07, Paul Durrant wrote:
>> -Original Message-
>> From: Julien Grall
>> Sent: 01 April 2020 14:42
>>
>> On 27/03/2020 18:50, Paul Durrant wrote:
>> Also, in the case of XEN_DOMCTL_setdomaincontext, the buffer is not
>> meant to be modified by the hypervisor. So I would rath
On Mon, Apr 6, 2020 at 11:24 AM Andrew Cooper wrote:
>
> On 06/04/2020 18:16, Tamas K Lengyel wrote:
> > On Fri, Apr 3, 2020 at 6:44 AM Andrew Cooper
> > wrote:
> >> On 03/04/2020 13:32, Anastassios Nanos wrote:
> >>> Hi all,
> >>>
> >>> I am trying to understand how live-migration happens in xe
On 03.04.2020 17:45, Jürgen Groß wrote:
> On 03.04.20 17:33, Jan Beulich wrote:
>> On 03.04.2020 17:12, Jürgen Groß wrote:
>>> On 03.04.20 16:31, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -353,6 +353,16 @
On 06.04.2020 13:54, Jürgen Groß wrote:
> On 06.04.20 13:11, Jan Beulich wrote:
>> On 06.04.2020 13:00, Ian Jackson wrote:
>>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event
>>> channels dependant on vcpus"):
There are no correlation between event channels and vCP
On Mon, Mar 23, 2020 at 04:43:18PM +, Peter Maydell wrote:
> The function usbback_packet_complete() currently takes a USBPacket*,
> which must be a pointer to the packet field within a struct
> usbback_req; the function uses container_of() to get the struct
> usbback_req* given the USBPacket*.
> On Apr 3, 2020, at 9:27 PM, Julien Grall wrote:
>
> On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini
> wrote:
>>
>> On Thu, 2 Apr 2020, Julien Grall wrote:
>>> As we discussed on Tuesday, the cost for other vCPUs is only going to be a
>>> trap to the hypervisor and then back again. The cost
On 06.04.2020 12:34, Paul Durrant wrote:
>>> Do you think this should also appear in a comment? Do we really care?
>>> Nothing fundamentally prevents
>> the mechanism being used for HVM state, but that may introduce an ordering
>> dependency.
>>
>> I don't particularly like the idea to let the co
On 06/04/2020 18:46, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> spurious and premature bus transactions as s
On 06/04/2020 18:58, George Dunlap wrote:
On Apr 3, 2020, at 9:27 PM, Julien Grall wrote:
On Fri, 3 Apr 2020 at 20:41, Stefano Stabellini wrote:
On Thu, 2 Apr 2020, Julien Grall wrote:
As we discussed on Tuesday, the cost for other vCPUs is only going to be a
trap to the hypervisor an
flight 149462 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149462/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ee026ea78b0e32a9ffbaf0040afe91de8ae2179c
baseline version:
ovmf ef5dcba975ee3b4c29b19
flight 149458 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149458/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
144861
test-amd6
flight 149469 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149469/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd broken
test-amd64-i386-libvirt-pair
Anthony PERARD writes:
> On Mon, Apr 06, 2020 at 06:50:41PM +0200, Philippe Mathieu-Daudé wrote:
>> On 4/6/20 6:42 PM, Anthony PERARD wrote:
>> > Since 7f5d9b206d1e ("object-add: don't create return value if
>> > failed"), qmp_object_add() don't write any value in 'ret_data', thus
>> > has random
flight 149482 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149482/
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
67 matches
Mail list logo
