From: SeongJae Park
The number of empty lines between functions in the xenbus.c is
inconsistent. This trivial style cleanup commit fixes the file to
consistently place only one empty line.
Acked-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/xenbus.c | 7
From: SeongJae Park
A driver's 'reclaim_memory' callback can race with 'probe' or 'remove'
because it will be called whenever memory pressure is detected. To
avoid such race, this commit embeds a spinlock in each 'xenbus_device'
and make 'xenbus' to hold the lock while the corresponded
From: SeongJae Park
A few of static variables in blkback have 'xen_blkif_' prefix, though it
is unnecessary for static variables. This commit removes such prefixes.
Reviewed-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/blkback.c | 37
On Thu, Jan 23, 2020 at 10:21:09AM +0100, Thomas Zimmermann wrote:
> At the end of a commit, atomic helpers can generate a VBLANK event
> automatically. Originally implemented for writeback connectors, the
> functionality can be used by any driver and/or hardware without proper
> VBLANK interrupt.
Sorry for jumping in late
On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
> The atomic helpers automatically send out fake VBLANK events if no
> vblanking has been initialized. This would apply to xen, but xen has
> its own vblank logic. To avoid interfering with the atomic helpers,
> disable
From: SeongJae Park
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and is increased on demand while processing
the I/O requests. If current I/O requests handling is finished or 100
milliseconds has passed since last I/O requests handling, it
From: SeongJae Park
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
From: SeongJae Park
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
From: Julien Grall
Commit 8916fcf4577 "x86/domain: compile with lock_profile=y enabled"
allowed the struct domain to use more than a PAGE_SIZE (i.e 4096).
However, the function free_domheap_struct() will only free the first
page.
We could modify the free part to free the correct number of
On Thu, Jan 23, 2020 at 10:21:23AM +0100, Thomas Zimmermann wrote:
> The atomic helpers automatically send out fake VBLANK events if no
> vblanking has been initialized. This would apply to xen, but xen has
> its own vblank logic. To avoid interfering with the atomic helpers,
> disable automatic
flight 146529 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146529/
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
Hi
Am 27.01.20 um 10:53 schrieb Oleksandr Andrushchenko:
> Sorry for jumping in late
>
> On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
>> The atomic helpers automatically send out fake VBLANK events if no
>> vblanking has been initialized. This would apply to xen, but xen has
>> its own vblank
On 1/27/20 1:59 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 27.01.20 um 10:53 schrieb Oleksandr Andrushchenko:
>> Sorry for jumping in late
>>
>> On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
>>> The atomic helpers automatically send out fake VBLANK events if no
>>> vblanking has been initialized.
flight 146526 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146526/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 146505
test-amd64-i386-qemut-rhel6hvm-amd
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 27 January 2020 13:00
> To: Durrant, Paul
> Cc: xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] live migration from 4.12 to 4.13 fails due to
> qemu-xen bug
>
> Am Mon, 27 Jan 2020 11:54:37 +
> schrieb
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Olaf Hering
> Sent: 27 January 2020 11:30
> To: xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] live migration from 4.12 to 4.13 fails due to
> qemu-xen bug
>
> Am Mon, 13 Jan 2020
Cc Roger
On Sun, Jan 19, 2020 at 11:30:42PM -0800, Roman Shaposhnik wrote:
> Hi!
>
> I've just tried this with Xen 4.13.0 and it seems like that is still
> not supported.
>
> This makes me curious if anybody is working on this and whether
> there's anything we can do to help accelerate the
On Fri, Jan 17, 2020 at 07:12:11PM +, Lars Kurth wrote:
> I propose to tally the votes after March 31st. You can reply via
> +1: for proposal
> -1: against proposal
> in public or private.
+1
___
Xen-devel mailing list
On Mon, Jan 20, 2020 at 11:52:17AM +, Anthony PERARD wrote:
> On Mon, Jan 20, 2020 at 11:50:50AM +, Anthony PERARD wrote:
> > Patch series available in this git branch:
> > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> > br.python3-default-v1
> >
> > Hi,
> >
> > I
On 27/01/2020 09:38, Julien Grall wrote:
> From: Julien Grall
>
> Commit 8916fcf4577 "x86/domain: compile with lock_profile=y enabled"
> allowed the struct domain to use more than a PAGE_SIZE (i.e 4096).
> However, the function free_domheap_struct() will only free the first
> page.
>
> We could
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and
Dear community members,
The CfP and Registration for the Xen Project Developer & Design Summit has been
open for a week. This is a quick reminder that the CfP for talks closes on
March 6th.
Information about the CfP can be found here:
https://events.linuxfoundation.org/xen-summit/program/cfp/
Am Mon, 13 Jan 2020 11:36:27 +0100
schrieb Olaf Hering :
> This HVM domU fails to live migrate from staging-4.12 to staging-4.13:
It turned out libxl does not configure qemu correctly at runtime:
libxl__build_device_model_args_new() uses 'qemu -machine xenfv', perhaps with
the assumption that
On Mon, Jan 27, 2020 at 12:30:21PM +, Wei Liu wrote:
> On Mon, Jan 20, 2020 at 11:52:17AM +, Anthony PERARD wrote:
> > On Mon, Jan 20, 2020 at 11:50:50AM +, Anthony PERARD wrote:
> > > Patch series available in this git branch:
> > >
Am Mon, 27 Jan 2020 11:54:37 +
schrieb "Durrant, Paul" :
> > Should the string "pc-i440fx-3.0" become a configure option?
> I suppose. Could we have "pc-i440fx" as the default, which libxl prefix
> matches against qemu's supported versions to select the latest?
I think the qemu machine
On 1/17/20 7:12 PM, Lars Kurth wrote:
> Hi all,
>
> for some time now we have been discussing the Xen Project Code of
> Conduct. The most recent set of feedback has been primarily around
> minor language issues (US vs UL English, etc.), which indicates to me
> that the proposal is ready to be
Sorry for the double "view" in the title, I will correct that asap
Alex
On 27.01.2020 15:23, Alexandru Stefan ISAILA wrote:
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new
On 27/01/2020 17:21, Roger Pau Monné wrote:
> On Mon, Jan 27, 2020 at 04:47:48PM +, Andrew Cooper wrote:
>> On 27/01/2020 16:43, Jan Beulich wrote:
>>> On 23.01.2020 19:06, Roger Pau Monne wrote:
There's no need to read the current values of LVT{0/1} for the
purposes of the function,
Current implementation of hvm_asid_flush_vcpu is not safe to use
unless the target vCPU is either paused or the currently running one,
as it modifies the generation without any locking.
Fix this by using atomic operations when accessing the generation
field, both in hvm_asid_flush_vcpu_asid and
Hello,
The following series aims to improve the TLB flush times when running
nested Xen, and it's specially beneficial when running in shim mode.
Only the HAP guest TLB flush is improved, the shadow paging TLB flush is
left as-is, and can be improved later if there's interest.
For a reference
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional
Introduce a specific flag to request a HVM guest TLB flush, which is
an ASID/VPID tickle that forces a linear 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 require linear
TLB flushes as Xen
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since
The returned type wants to be bool instead of int.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/include/asm-x86/flushtlb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h
index
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
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:
flight 146538 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146538/
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
Hi Emil
Am 27.01.20 um 19:12 schrieb Emil Velikov:
> Hi Thomas,
>
> On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann wrote:
>
>> @@ -174,12 +174,22 @@ struct drm_crtc_state {
>> * @no_vblank:
>> *
>> * Reflects the ability of a CRTC to send VBLANK events. This state
On Mon, Jan 27, 2020 at 04:47:48PM +, Andrew Cooper wrote:
> On 27/01/2020 16:43, Jan Beulich wrote:
> > On 23.01.2020 19:06, Roger Pau Monne wrote:
> >> There's no need to read the current values of LVT{0/1} for the
> >> purposes of the function, which seem to be to save the currently
> >>
On Mon, Jan 27, 2020 at 03:43:12PM +0100, Jan Beulich wrote:
> On 27.01.2020 15:33, Xia, Hongyan wrote:
> > On Thu, 2020-01-16 at 13:04 +0100, Jan Beulich wrote:
> >> ...
> >>
> >>> +void free_xen_pagetable(void *v)
> >>> +{
> >>> +mfn_t mfn = v ? virt_to_mfn(v) : INVALID_MFN;
> >>> +
> >>> +
> -Original Message-
> From: Ian Jackson
> Sent: 27 January 2020 16:46
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
>
> Subject: [PATCH]
Hi Thomas,
On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann wrote:
> @@ -174,12 +174,22 @@ struct drm_crtc_state {
> * @no_vblank:
> *
> * Reflects the ability of a CRTC to send VBLANK events. This state
> -* usually depends on the pipeline configuration, and
> -Original Message-
> From: Xen-devel On Behalf Of
> Juergen Gross
> Sent: 27 January 2020 16:51
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George
> Dunlap ; Andrew Cooper
> ; Ian Jackson
>
On 1/27/20 3:07 PM, Xia, Hongyan wrote:
> On Mon, 2020-01-27 at 15:43 +0100, Jan Beulich wrote:
>> On 27.01.2020 15:33, Xia, Hongyan wrote:
>>> ...
>>>
>>> Reflecting back to your comment in v3 about whether the new Xen
>>> page
>>> table mapping APIs (map/unmap_xen_pagetable) are really
On Thu, Jan 16, 2020 at 01:04:16PM +0100, Jan Beulich wrote:
[...]
> > +/* v can point to an entry within a table or be NULL */
> > +void unmap_xen_pagetable(const void *v)
>
> Why "entry" in the comment?
IIRC there would be cases that umap_xen_pagetable would be called with a
pointer to a PTE.
Currently when booting native on AMD hardware, cpuidmask_defaults._1cd gets
configured with the HYPERVISOR bit before native CPUID is scanned for feature
bits.
This results in cpu_has_hypervisor becoming set as part of identify_cpu(), and
ends up appearing in the raw and host CPU policies.
... and enable it after exiting S-state. Otherwise accumulated
output in serial buffer might easily trigger the watchdog if it's
still enabled after entering sync transmission mode.
The issue observed on machines which, unfortunately, generate non-0
output in CPU offline callbacks.
The existing RCU barrier implementation is prone to a deadlock scenario
due to IRQs being re-enabled inside stopmachine context. If due to a race
IRQs are re-enabled on some of CPUs and softirqs are allowed to be
processed in stopmachine, i.e. what currently happens in rcu_barrier(),
timer
On Mon, Jan 27, 2020 at 03:27:40PM +0100, Jan Beulich wrote:
> On 27.01.2020 15:12, George Dunlap wrote:
> > I have drafted an explicit policy on what is (generally) required to
> > check a patch in. It's been through several rounds, and v4 has been
> > acked [1].
> >
> > I've had informal
Rojer,
> You can also start xl devd manually, as that will give you verbose
> output of whats going on. In the driver domain:
> # killall xl
> # xl -vvv devd -F
> That should give you detailed output of what's going on in the driver
> domain, can you paste the output you get from the driver
On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
> On 27.01.20 14:16, Ilpo Järvinen wrote:
> > Hi,
> >
> > I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
> > 5.4 based kernels worked fine and there seems to have been some changes in
> > drivers/xen post-5.4 so
On 27/01/2020 16:45, Ian Jackson wrote:
> $ git-grep libxenctrl | wc -l
> 99
> $ git-grep libxc | wc -l
> 206
> $ git-grep libxenlight | wc -l
> 48
> $ git-grep libxl | wc -l
> 13433
> $ git-grep LibXen | wc -l
> 2
> $
>
> Reported-by: Paul Durrant
> Signed-off-by: Ian Jackson
Acked-by: Andrew
Thanks for getting the other patches in the series onto master, Jan.
This is the only patch out of this series that did not make it through,
so I keeping my comments here.
On 23.01.20 11:26, Jan Beulich wrote:
On 22.01.2020 23:30, Eslam Elnikety wrote:
Decouple the microcode indexing
flight 146535 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146535/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 1/24/20 7:32 PM, Nick Rosbrook wrote:
> Sorry for the late reply on this one.
>
>> +func NewDomainConfig(t DomainType) (*DomainConfig, error) {
>> + var cconfig C.libxl_domain_config
>> +
>> + C.libxl_domain_config_init()
>> + C.libxl_domain_build_info_init_type(_info,
>>
DIRECTORY_PART was missing in docs/misc/xenstore.txt. Add it.
Signed-off-by: Juergen Gross
---
docs/misc/xenstore.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ae1b6a8c6e..65570183b6 100644
--- a/docs/misc/xenstore.txt
+++
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
---
Using XENLOG_ERR level since this is only used in debug paths (ie. it's
expected the user already has loglvl=all set). Also use %pd to print the domain
ids.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 82 +--
1 file changed, 41
During VM forking we'll copy the parent domain's parameters to the client,
including the HAP shadow memory setting that is used for storing the domain's
EPT. We'll copy this in the hypervisor instead doing it during toolstack launch
to allow the domain to start executing and unsharing memory
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:
When plugging a hole in the target physmap don't use the access permission
returned by __get_gfn_type_access as it can be non-sensical, leading to
spurious vm_events being sent out for access violations at unexpected
locations. Make use of p2m->default_access instead.
Signed-off-by: Tamas K
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
Currently the hvm parameters are only accessible via the HVMOP hypercalls. In
this patch we introduce a new function that can copy both the hvm context and
parameters directly into a target domain. No functional changes in existing
code.
Signed-off-by: Tamas K Lengyel
---
v6: finish addressing
Use __get_gfn_type_access instead of p2m->get_entry to trigger page-forking
when the mem_access permission is being set on a page that has not yet been
copied over from the parent.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_access.c | 5 ++---
1 file changed, 2 insertions(+), 3
The owner domain of shared pages is dom_cow, use that for get_page
otherwise the function fails to return the correct page. Fixing the
error now and simplifying the checks since we can't have any shared
entries with dom_cow being NULL.
Signed-off-by: Tamas K Lengyel
---
v6: use simplified check
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
flight 146539 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146539/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Mon, 27 Jan 2020, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
> > On 27.01.20 14:16, Ilpo Järvinen wrote:
> > > Hi,
> > >
> > > I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
> > > 5.4 based kernels worked fine and
flight 146536 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146536/
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. 146121
On Mon, 27 Jan 2020, Boris Ostrovsky wrote:
> (Sorry, with proper addressing now)
>
> On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
> >
> >
> > On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
> >>
> Loading Linux 5.5.0-accecn30 ...
>
> .[5;22H [ initrd.img-5.5.0-acc
On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
>
>
> On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
>> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
>>> On 27.01.20 14:16, Ilpo Järvinen wrote:
Hi,
I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in
flight 146534 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146534/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 146526
test-armhf-armhf-libvirt 14
On Sat, Jan 25, 2020 at 05:11:18PM +, Andrew Cooper wrote:
> On 25/01/2020 03:26, Bobby Eshleman wrote:
> > On Fri, Jan 24, 2020 at 01:41:38PM +, Andrew Cooper wrote:
> >> Other areas where you can reduce the minimum build would be to put some
> >> defaults into the defconfig, such as
flight 146542 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146542/
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
(Sorry, with proper addressing now)
On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
>
>
> On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
>>
Loading Linux 5.5.0-accecn30 ...
.[5;22H [ initrd.img-5.5.0-acc 16.52MiB 100% 10.23MiB/s
].[5;1HSetting up swapspace version
flight 146540 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146540/
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 146537 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146537/
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
On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
>> On 27.01.20 14:16, Ilpo Järvinen wrote:
>>> Hi,
>>>
>>> I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
>>> 5.4 based kernels worked fine and there seems
The CONTROL command (former DEBUG command) isn't specified in the
xenstore protocol doc. Add it.
Signed-off-by: Juergen Gross
---
docs/misc/xenstore.txt | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/docs/misc/xenstore.txt
flight 146541 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146541/
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 Fri, Jan 24, 2020 at 10:24:44AM +, Vincenzo Frascino wrote:
> Hi Boqun Feng,
>
> On 24/01/2020 06:32, Boqun Feng wrote:
> > Hi Vincenzo,
> >
>
> [...]
>
> >>
> >> I had a look to your patches and overall, I could not understand why we
> >> can't
> >> use the arch_timer to do the same
flight 146546 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146546/
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 146547 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146547/
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 27.01.20 16:19, Paul Durrant wrote:
... specification.
This was added by commit 0ca64ed8 "xenstore: add support for reading
directory with many children" but not added to the specification at that
point. A version of xenstored supporting the command was first released
in Xen 4.9.
On 27.01.20 16:33, Ian Jackson wrote:
Paul Durrant writes ("[PATCH] docs: retrospectively add XS_DIRECTORY_PART to the
xenstore protocol..."):
... specification.
This was added by commit 0ca64ed8 "xenstore: add support for reading
directory with many children" but not added to the
flight 146532 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146532/
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
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@citrix.com]
> Sent: 27 January 2020 15:49
> To: Jürgen Groß
> Cc: Durrant, Paul ; xen-devel@lists.xenproject.org;
> Andrew Cooper ; George Dunlap
> ; Jan Beulich ; Julien Grall
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini ;
Ian Jackson writes ("[PATCH v3 00/10] libxl: event: Fix hang for some
applications"):
> The meat here, including a description of the bug, is in:
> libxl: event: Fix hang when mixing blocking and eventy calls
>
> This is all now Reviewed-by and Tested-by George, so it is ready to be
>
$ git-grep libxenctrl | wc -l
99
$ git-grep libxc | wc -l
206
$ git-grep libxenlight | wc -l
48
$ git-grep libxl | wc -l
13433
$ git-grep LibXen | wc -l
2
$
Reported-by: Paul Durrant
Signed-off-by: Ian Jackson
---
docs/man/xl.1.pod.in | 2 +-
On 27/01/2020 16:43, Jan Beulich wrote:
> On 23.01.2020 19:06, Roger Pau Monne wrote:
>> There's no need to read the current values of LVT{0/1} for the
>> purposes of the function, which seem to be to save the currently
>> selected vector: in the destination modes used (ExtINT and NMI) the
>>
Paul Durrant writes ("[PATCH] docs/designs: Add a design document for
transparent live migration"):
> It has become apparent to some large cloud providers that the current
> model of co-operative migration of guests under Xen is not usable as it
> places trust in software running inside the
Here is v2 of the work to plumb CPUID/MSR data into the migration stream.
Patches 1 and 2 are cleanup. 3-8 are concerned with introducing the
STATIC_DATA_END record. 9-11 are some libxl work to reposition CPUID
construction during domain create. 12-14 are the introduction of the
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/python/xen/migration/libxc.py | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/tools/python/xen/migration/libxc.py
Migration v3 is in the process of being introduced, meaning that the code has
to cope with both versions. Use an explicit 2 for now.
For the verify-stream-v2 and convert-legacy-stream scripts, update text to say
"v2 (or later)". What matters is the distinction vs legacy streams.
Signed-off-by:
Migration data can be split into two parts - that which is invariant of
guest execution, and that which is not. Separate these two with the
STATIC_DATA_END record.
The short term, we want to move the x86 CPU Policy data into the stream.
In the longer term, we want to provisionally send the
A v3 stream can compatibly read a v2 stream by inferring the position of the
STATIC_DATA_END record.
v2 compatibility is only needed for x86. No other architectures exist yet,
but they will have a minimum of v3 when introduced.
The x86 HVM compatibility point being in handle_page_data() (which
Higher level toolstacks may wish to know when the static data is complete, so
introduce a restore_callback for the purpose.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
v2:
* Split/rearranged from v1
---
tools/libxc/include/xenguest.h | 3 +++
This will be needed shortly to provide backwards compatiblity for migration
streams which do not have CPUID information contained within them.
No functional change yet.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
v2:
* Split/rearranged from v1
---
These functions should never have been exposed. They don't have external
users, and can't usefully be used for several reasons.
Move libxl_cpuid_{set,apply_policy}() to being internal functions, and leave
an equivalent of the nop stubs in the API for caller compatibility.
Signed-off-by: Andrew
On 27.01.2020 15:33, Xia, Hongyan wrote:
> On Thu, 2020-01-16 at 13:04 +0100, Jan Beulich wrote:
>> ...
>>
>>> +void free_xen_pagetable(void *v)
>>> +{
>>> +mfn_t mfn = v ? virt_to_mfn(v) : INVALID_MFN;
>>> +
>>> +if ( system_state != SYS_STATE_early_boot )
>>> +
1 - 100 of 137 matches
Mail list logo
