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 chec
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
uti
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
uti
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 callbacks
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 +---
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: 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 pages,
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.
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 vb
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 automa
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
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 'x
> -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 11:3
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 lo
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. T
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 vot
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
Xen-devel@lists.xenproject.org
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 effor
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 th
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:
> > > https://xenbits.xen.org/git-http/people/aperard/xen-u
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 mo
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 1
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 varia
> -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 "Durran
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
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 xc_altp2m_set_visibilit
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 perhaps they broke something?
Loading Linux 5.5.0-accecn30 ...
.[5;22H [ initrd.img-5.5.0-acc 16.52MiB 100% 10.23
From: Julien Grall
The HVM context may not fill up the full buffer passed by the caller.
While we report corectly the size of the context, we will still be
copying back the full size of the buffer.
As the buffer is allocated through xmalloc(), we will be copying some
bits from the previous alloc
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 assent from all committers, but just to dot all our
i's and cross all our t's, it's probably worth having a vote of the
committers,
flight 146533 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146533/
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 1
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 assent from all committers, but just to dot all our
> i's and cross all our t's
On 27/01/2020, 14: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 assent from all committers, but just to dot all our
i's a
On Mon, Jan 27, 2020 at 12:27:18PM +, Wei Liu wrote:
> Cc Roger
Thanks :).
> 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.
No, there hasn't been much progress on this
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 )
> > +free_xen_pagetable_new(mfn);
>
> The condition is (partly) redu
The {save,restore}_callback helpers can have their scope reduced vastly, and
helper_setcallbacks_{save,restore}() doesn't need to use a ternary operator to
write 0 (meaning NULL) into an already zeroed structure.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
Introduce a new static_data() hook which is responsible for writing out
any static data records. The HVM side continues to be a no-op, while
the PV side moves write_x86_pv_info() into this earlier hook. The the
common code writes out a STATIC_DATA_END record, and the stream version
is bumped to 3
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
X86_{CPUID,MSR}
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
b/tools/python/xen/migration/
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 static
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 i
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 +++
tools/li
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
---
tools/
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 C
These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
hypercall.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
CC: Marek Marczykowski-Górecki
For now, the data are just stashed, and discarded at the end.
A future change will restore the data, once libxl has been adjusted to avoid
clobbering the data.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_sr_comm
This is partly to adjust the description of 'k' and 's' seeing as they have
changed, but mostly restructuring the information for clarity.
In particular, use indentation to clearly separate the areas discussing libxl
format from xend format. In addition, extend the xend format section to
discuss
On Mon, Jan 27, 2020 at 12:36:23PM +, Anthony PERARD wrote:
> 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
CPUID handling needs to be earlier in construction. Move it from its current
position in libxl__build_post() to libxl__build_pre() for fresh builds, and
libxl__srm_callout_callback_static_data_done() for the migration/resume case.
Later changes will make the migration/resume case conditional on w
With all other plumbing in place, obtain the CPU Policy from Xen and
write it into the migration stream.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_sr_common_x86.c | 50
tools/libxc/xc_sr_common_x86.h | 6 +
With all other pieces in place, it is now safe to restore the CPUID and MSR
data in the migration stream, rather than discarding them and using the higher
level toolstacks compatibility logic.
While this is a small patch, it has large implications for migrated/resumed
domains. Most obviously, the
Pre Xen-4.14 streams will not contain any CPUID/MSR information. There is
nothing libxc can do about this, and will have to rely on the higher level
toolstack to provide backwards compatibility.
To facilitate this, extend the static_data_done() callback, highlighting the
missing information, and
On Mon, Jan 20, 2020 at 11:50:53AM +, Anthony PERARD wrote:
> Main reason, newer version of QEMU doesn't support python 2.x anymore.
> Second main reason, python2 is EOL.
>
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing l
To fix CPUID handling, libxl__build_pre() is going to have to distinguish
between a brand new VM vs one which is being migrated-in/resumed.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony PERARD
v2:
* New. This is c/s aacc1430064 "tools/libxl:
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 )
>>> +free_xen_pagetable_n
On Mon, Jan 27, 2020 at 02:40:40PM +, Wei Liu wrote:
> On Mon, Jan 27, 2020 at 12:36:23PM +, Anthony PERARD wrote:
> > 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 +0
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 perhaps they broke something?
I can't reproduce your problem. Just booted a VM wi
flight 146531 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On 27.01.2020 15:34, Andrew Cooper wrote:
> With all other pieces in place, it is now safe to restore the CPUID and MSR
> data in the migration stream, rather than discarding them and using the higher
> level toolstacks compatibility logic.
>
> While this is a small patch, it has large implication
flight 146530 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146530/
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
test-amd64-amd64-xl-
Forgot to set 'To:' correctly.
On Mon, Jan 27, 2020 at 03:28:36PM +0100, Roger Pau Monné wrote:
> On Mon, Jan 27, 2020 at 12:27:18PM +, Wei Liu wrote:
> > Cc Roger
>
> Thanks :).
>
> > On Sun, Jan 19, 2020 at 11:30:42PM -0800, Roman Shaposhnik wrote:
> > > Hi!
> > >
> > > I've just tried th
On 27.01.2020 14:48, Julien Grall wrote:
> From: Julien Grall
>
> The HVM context may not fill up the full buffer passed by the caller.
> While we report corectly the size of the context, we will still be
> copying back the full size of the buffer.
>
> As the buffer is allocated through xmalloc(
On Mon, 27 Jan 2020, 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 perhaps they broke som
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 necessary,
> > I
> > agree in the end they will just
Lars Kurth writes ("[Vote] For Xen Project Code of Conduct (deadline March
31st)"):
> People allowed to vote on behalf of the Hypervisor project are:
> Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R
> Wilk, Stefano Stabellini, Wei Liu and Paul Durrant (as Release Mana
... 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.
Signed-off-by: Paul Durrant
---
Cc: Juergen Gross
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.
Signed-off-
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 specification at that
> point. A version of x
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 specificatio
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
Jürgen Groß writes ("Re: [PATCH] docs: retrospectively add XS_DIRECTORY_PART to
the xenstore protocol..."):
> On 27.01.20 16:33, Ian Jackson wrote:
> > Paul Durrant writes ("[PATCH] docs: retrospectively add XS_DIRECTORY_PART
> > to the xenstore protocol..."):
> >> ... specification.
> >>
> >> Th
On 27/01/2020 14:51, Jan Beulich wrote:
> On 27.01.2020 15:34, Andrew Cooper wrote:
>> With all other pieces in place, it is now safe to restore the CPUID and MSR
>> data in the migration stream, rather than discarding them and using the
>> higher
>> level toolstacks compatibility logic.
>>
>> Whi
> -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 ; W
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
> committed
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 guest, which is likely
beyond the provider's trust boundary.
This patch introduces a proposal for a 'transparent'
On 23.01.2020 19:06, Roger Pau Monne wrote:
> The Intel SDM states:
>
> "When an illegal vector value (0 to 15) is written to a LVT entry and
> the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
> illegal vector error, without regard to whether the mask bit is set or
> whether
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
> vector field is ignored and hence can be set to 0.
$ 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 +-
docs/specs/libxc-migration-strea
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 guest,
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
>> vecto
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
+++
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 C
> -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] do
> -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
> Subject:
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 necessary,
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 1
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
> >> sel
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,
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.
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;
> >>> +
> >>> +
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(&cconfig)
>> + C.libxl_domain_build_info_init_type(&cconf
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 ot
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 on
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 hvm_asid_flush_vcp
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 434821aaf
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
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:
1 - 100 of 137 matches
Mail list logo
