Hello,
displ_be was compiled without zero-copy support early.
I have tried with the recompiled dom0 kernel, a result is the same.
Logs and configs (+displ_be’s CMakeCache.txt ) are attached.
Best regards,
Alexander
>Понедельник, 3 февраля 2020, 10:36 +03:00 от Oleksandr Andrushchenko <
flight 146716 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 145767
Tests which did not succee
On 04.02.2020 07:43, Jürgen Groß wrote:
> On 03.02.20 16:07, Jan Beulich wrote:
>> On 21.01.2020 09:43, Juergen Gross wrote:
>>> +static int hypfs_read(const struct hypfs_entry *entry,
>>> + XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long
>>> ulen)
>>> +{
>>> +struct xen
De-htmling...
---
From: Xen-devel On Behalf Of Jules
Sent: 03 February 2020 17:35
To: xen-devel@lists.xenproject.org
Cc: oleksandr_gryt...@epam.com; w...@xen.org
Subject: [Xen-devel] XEN Qdisk Ceph rbd support broken?
Hey,
I don’t know if it was this or a previous change in qdisk driver, but ca
flight 146717 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 04.02.20 09:48, Jan Beulich wrote:
On 04.02.2020 07:43, Jürgen Groß wrote:
On 03.02.20 16:07, Jan Beulich wrote:
On 21.01.2020 09:43, Juergen Gross wrote:
+static int hypfs_read(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr, unsigned long ulen)
+
On Tue, Feb 04, 2020 at 01:35:05AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Monday, February 3, 2020 8:19 PM
> >
> > When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
> > interrupts shouldn't be injected using the virtual interrupt delivery
> > mechanism unless
On Tue, Feb 04, 2020 at 01:39:44AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Monday, February 3, 2020 8:19 PM
> >
> > When VM_EXIT_ACK_INTR_ON_EXIT is set in the vmexit control vmcs
>
> set->cleared
>
> > register the bit 31 of VM_EXIT_INTR_INFO must be 0, in order to denote
On 03.02.2020 18:37, Roger Pau Monne wrote:
> @@ -182,6 +192,11 @@ void nvmx_vcpu_destroy(struct vcpu *v)
> free_domheap_page(v->arch.hvm.vmx.vmwrite_bitmap);
> v->arch.hvm.vmx.vmwrite_bitmap = NULL;
> }
> +if ( nvmx->msr_merged )
> +{
> +free_domheap_page(nvm
From: Julien Grall
Unlike shadow_enable(), hap_enable() can only be called once during
domain creation and with the mode equal to mode equal to
PG_external | PG_translate | PG_refcounts.
If it were called twice, then we might have something interesting
problem as the p2m tables would be re-alloc
From: Julien Grall
Signed-off-by: Julien Grall
---
xen/arch/x86/mm/hap/hap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3d93f3451c..31362a31b6 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/
From: Julien Grall
Hi all,
This series contain a couple of clean-up/hardening for the function
hap_enable().
Cheers,
Julien Grall (2):
xen/x86: hap: Fix coding style in hap_enable()
xen/x86: hap: Clean-up and harden hap_enable()
xen/arch/x86/mm/hap/hap.c | 21 +
1 fil
From: Stefan Bader
libxenstore3.0 in Xen 4.8 had this function. We don't really want to
bump the ABI version (soname) just for this, since we don't think
there are actual callers anywhere. But tools complain about the
symbol going away.
So, provide a function xs_restrict which conforms to the
These were posted before in October 2018 but never made it upstream
for some reason. They seem to have been sufficiently reviewed, and I
intend to commit them soon. I'm reposting now, with no changes,
in case anyone wants to object.
Ian Jackson (1):
INSTALL: Mention kconfig
Stefan Bader (1):
From: Ian Jackson
Firstly, add a reference to the documentation for the kconfig system.
Secondly, warn the user about the XEN_CONFIG_EXPERT problem.
Signed-off-by: Ian Jackson
Reviewed-by: Doug Goldstein
---
v2: Fix typos
---
INSTALL | 20
1 file changed, 20 insertions(
On 03.02.2020 18:37, Roger Pau Monne wrote:
> @@ -587,6 +588,16 @@ static void update_msrbitmap(struct vcpu *v, uint32_t
> shadow_ctrl)
>v->arch.hvm.vmx.msr_bitmap->write_high,
>sizeof(msr_bitmap->write_high) * 8);
>
> +/*
> + * Nested VMX doesn't support
On 04.02.2020 10:34, Ian Jackson wrote:
> From: Ian Jackson
>
> Firstly, add a reference to the documentation for the kconfig system.
>
> Secondly, warn the user about the XEN_CONFIG_EXPERT problem.
>
> Signed-off-by: Ian Jackson
> Reviewed-by: Doug Goldstein
Just in case it helps:
Acked-by:
On 04.02.2020 10:23, Roger Pau Monné wrote:
> On Tue, Feb 04, 2020 at 01:35:05AM +, Tian, Kevin wrote:
>>> From: Roger Pau Monne
>>> Sent: Monday, February 3, 2020 8:19 PM
>>>
>>> When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
>>> interrupts shouldn't be injected using the vi
On 04.02.2020 10:21, Jürgen Groß wrote:
> On 04.02.20 09:48, Jan Beulich wrote:
>> On 04.02.2020 07:43, Jürgen Groß wrote:
>>> On 03.02.20 16:07, Jan Beulich wrote:
On 21.01.2020 09:43, Juergen Gross wrote:
> +static int hypfs_read(const struct hypfs_entry *entry,
> +
> From: Jan Beulich
> Sent: Tuesday, February 4, 2020 5:50 PM
>
> On 04.02.2020 10:23, Roger Pau Monné wrote:
> > On Tue, Feb 04, 2020 at 01:35:05AM +, Tian, Kevin wrote:
> >>> From: Roger Pau Monne
> >>> Sent: Monday, February 3, 2020 8:19 PM
> >>>
> >>> When doing a virtual vmexit (ie: a vm
On Tue, Feb 04, 2020 at 09:34:10AM +, Julien Grall wrote:
> From: Julien Grall
>
> Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/ma
On 04.02.20 10:58, Jan Beulich wrote:
On 04.02.2020 10:21, Jürgen Groß wrote:
On 04.02.20 09:48, Jan Beulich wrote:
On 04.02.2020 07:43, Jürgen Groß wrote:
On 03.02.20 16:07, Jan Beulich wrote:
On 21.01.2020 09:43, Juergen Gross wrote:
+static int hypfs_read(const struct hypfs_entry *entry,
On Tue, Feb 04, 2020 at 09:34:11AM +, Julien Grall wrote:
> From: Julien Grall
>
> Unlike shadow_enable(), hap_enable() can only be called once during
> domain creation and with the mode equal to mode equal to
^ equals to
> PG_external | PG_translate | PG_r
On Mon, Feb 3, 2020 at 4:37 PM David Woodhouse wrote:
>
> On Mon, 2020-02-03 at 14:00 +, Julien Grall wrote:
> > Hi David,
> >
> > On 01/02/2020 00:33, David Woodhouse wrote:
> > > From: David Woodhouse
> >
> > I am a bit concerned with this change, particularly the consequence this
> > have
On Tue, 2020-02-04 at 11:00 +, George Dunlap wrote:
> On Mon, Feb 3, 2020 at 4:37 PM David Woodhouse wrote:
> >
> > On Mon, 2020-02-03 at 14:00 +, Julien Grall wrote:
> > > Hi David,
> > >
> > > On 01/02/2020 00:33, David Woodhouse wrote:
> > > > From: David Woodhouse
> > >
> > > I am
On 04/02/2020 10:51, Roger Pau Monné wrote:
On Tue, Feb 04, 2020 at 09:34:11AM +, Julien Grall wrote:
From: Julien Grall
Unlike shadow_enable(), hap_enable() can only be called once during
domain creation and with the mode equal to mode equal to
^ eq
On 03.02.2020 20:48, Andrew Cooper wrote:
> On 31/01/2020 16:44, Jan Beulich wrote:
>> Emulation requiring device model assistance uses a form of instruction
>> re-execution, assuming that the second (and any further) pass takes
>> exactly the same path. This is a valid assumption as far as use of
On Tue, Feb 04, 2020 at 10:32:47AM +0100, Jan Beulich wrote:
> On 03.02.2020 18:37, Roger Pau Monne wrote:
> > @@ -182,6 +192,11 @@ void nvmx_vcpu_destroy(struct vcpu *v)
> > free_domheap_page(v->arch.hvm.vmx.vmwrite_bitmap);
> > v->arch.hvm.vmx.vmwrite_bitmap = NULL;
> > }
>
On Tue, 2020-02-04 at 11:06 +, David Woodhouse wrote:
>
> I still don't really get it. What if the zone boundary is at MFN 0x300?
>
> What prevents the buddy allocator from merging a range a 0x200-0x2FF
> with another from 0x300-0x3FF, creating a single range 0x200-0x400
> which crosses nodes
On Fri, Jan 31, 2020 at 05:49:21PM +, Wei Liu wrote:
> Push hypervisor_ap_setup down to smp_callin.
>
> Take the chance to replace xen_guest with cpu_has_hypervisor.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Roger Pau Monné
> Reviewed-by: Jan Beulich
> ---
> xen/arch/x86/smpboot.c | 10 ++
On Tue, Feb 04, 2020 at 11:20:38AM +, Wei Liu wrote:
> On Fri, Jan 31, 2020 at 05:49:21PM +, Wei Liu wrote:
> > Push hypervisor_ap_setup down to smp_callin.
> >
> > Take the chance to replace xen_guest with cpu_has_hypervisor.
> >
> > Signed-off-by: Wei Liu
> > Reviewed-by: Roger Pau Mon
On 04.02.2020 12:13, Roger Pau Monné wrote:
> On Tue, Feb 04, 2020 at 10:32:47AM +0100, Jan Beulich wrote:
>> On 03.02.2020 18:37, Roger Pau Monne wrote:
>>> @@ -182,6 +192,11 @@ void nvmx_vcpu_destroy(struct vcpu *v)
>>> free_domheap_page(v->arch.hvm.vmx.vmwrite_bitmap);
>>> v->a
On Tue, Feb 04, 2020 at 11:11:11AM +, Julien Grall wrote:
>
>
> On 04/02/2020 10:51, Roger Pau Monné wrote:
> > On Tue, Feb 04, 2020 at 09:34:11AM +, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > Unlike shadow_enable(), hap_enable() can only be called once during
> > > domain
On 04.02.2020 11:48, Jürgen Groß wrote:
> On 04.02.20 10:58, Jan Beulich wrote:
>> On 04.02.2020 10:21, Jürgen Groß wrote:
>>> On 04.02.20 09:48, Jan Beulich wrote:
On 04.02.2020 07:43, Jürgen Groß wrote:
> On 03.02.20 16:07, Jan Beulich wrote:
>> On 21.01.2020 09:43, Juergen Gross wro
On 2/4/20 11:28 AM, Roger Pau Monné wrote:
> On Tue, Feb 04, 2020 at 11:11:11AM +, Julien Grall wrote:
>>
>>
>> On 04/02/2020 10:51, Roger Pau Monné wrote:
>>> On Tue, Feb 04, 2020 at 09:34:11AM +, Julien Grall wrote:
From: Julien Grall
Unlike shadow_enable(), hap_enable() c
On 23.01.2020 12:49, Jan Beulich wrote:
> 1: fix PoD accounting in guest_physmap_add_entry()
> 2: adjust non-PoD accounting in p2m_pod_decrease_reservation()
George?
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xe
On 04.02.20 12:28, Jan Beulich wrote:
On 04.02.2020 11:48, Jürgen Groß wrote:
On 04.02.20 10:58, Jan Beulich wrote:
On 04.02.2020 10:21, Jürgen Groß wrote:
On 04.02.20 09:48, Jan Beulich wrote:
On 04.02.2020 07:43, Jürgen Groß wrote:
On 03.02.20 16:07, Jan Beulich wrote:
On 21.01.2020 09:43
On 04/02/2020 11:28, Roger Pau Monné wrote:
On Tue, Feb 04, 2020 at 11:11:11AM +, Julien Grall wrote:
On 04/02/2020 10:51, Roger Pau Monné wrote:
On Tue, Feb 04, 2020 at 09:34:11AM +, Julien Grall wrote:
From: Julien Grall
Unlike shadow_enable(), hap_enable() can only be called o
Thanks, I welcome effort to make Xen more scalable. :-)
On Mon, Feb 03, 2020 at 06:36:53PM +, Hongyan Xia wrote:
> Rewrite the mapcache to be purely per-vCPU instead of partly per-vCPU
> and partly per-domain.
>
> This patch is needed to address performance issues when we start relying
> on
On 04.02.2020 12:44, Julien Grall wrote:
> Aside the MISRA, there are some cases where I feel the explicit
> comparisons make sense. But I don't have any rational for them and view
> this as a matter of taste. So I would leave it to the author of the
> patch the choice.
FWIW, I disagree on this
Dear community members,
In Lars' absence, I have volunteered to take over managing the Community
Call for now. Please note the change in meeting ID.
Please send me agenda items for this Thursday's community call.
A draft agenda is at
https://cryptpad.fr/pad/#/2/pad/edit/oSj9dSFY1OmHxfX0-oZKmEFL
On 04/02/2020 12:36, Jan Beulich wrote:
On 04.02.2020 12:44, Julien Grall wrote:
Aside the MISRA, there are some cases where I feel the explicit
comparisons make sense. But I don't have any rational for them and view
this as a matter of taste. So I would leave it to the author of the
patch the
From: Julien Grall
Unlike shadow_enable(), hap_enable() can only be called once during
domain creation and with the mode equal to mode equal to
PG_external | PG_translate | PG_refcounts.
If it were called twice, then we might have something interesting
problem as the p2m tables would be re-alloc
Hi all,
This series contains a couple of clean-up/hardening for the function
hap_enable().
Cheers,
Julien Grall (2):
xen/x86: hap: Fix coding style in hap_enable()
xen/x86: hap: Clean-up and harden hap_enable()
xen/arch/x86/mm/hap/hap.c | 21 +
1 file changed, 13 insert
Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
---
Changes in v2:
- Add Roger's reviewed-by
---
xen/arch/x86/mm/hap/hap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3d93f3451c..31362a31b
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 04 February 2020 13:06
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Wei Liu ; George Dunlap
> ; Andrew Cooper ;
> Grall, Julien ; Jan Beulich ; Roger
> Pau Monné
> Subject: [Xen-devel] [PATCH v2 2/2]
On 04/02/2020 13:16, Durrant, Paul wrote:
-Original Message-
From: Xen-devel On Behalf Of
Julien Grall
Sent: 04 February 2020 13:06
To: xen-devel@lists.xenproject.org
Cc: jul...@xen.org; Wei Liu ; George Dunlap
; Andrew Cooper ;
Grall, Julien ; Jan Beulich ; Roger
Pau Monné
Subject: [
From: Julien Grall
At the moment, assign_pages() relies on PG_state_inuse to be 0. This
makes the code slightly more difficult to understand.
Rework the code to explicitly check against PG_state_inuse.
Signed-off-by: Julien Grall
---
xen/common/page_alloc.c | 5 +++--
1 file changed, 3 insert
On 17.01.2020 20:12, Lars Kurth wrote:
> 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 Manager).
I have to admit that with certain parts
On 04.02.2020 14:33, Julien Grall wrote:
> At the moment, assign_pages() relies on PG_state_inuse to be 0. This
> makes the code slightly more difficult to understand.
I can certainly see where you're coming from, but ...
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2286,
On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
At the moment, assign_pages() relies on PG_state_inuse to be 0. This
makes the code slightly more difficult to understand.
I can certainly see where you're coming from, but ...
--- a/xen/common/page_alloc.c
++
On Mon, Feb 03, 2020 at 06:36:53PM +, Hongyan Xia wrote:
[...]
> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> index dd32712d2f..52971d2ecc 100644
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -69,12 +69,11 @@ void __init mapcache_override_c
Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
> On 30/01/2020 13:03, Dietmar Hahn wrote:
> > Hi,
> >
> > we use SLES12 with kernel-default-4.12.14-95.45.1.x86_64 and
> > xen-4.11.3_02-2.20.1.x86_64
> >
> > The dump kernel doesn't start after "echo c > /proc/sysrq_trigger".
>
On 04/02/2020 14:07, Dietmar Hahn wrote:
> Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
>> On 30/01/2020 13:03, Dietmar Hahn wrote:
>>> Hi,
>>>
>>> we use SLES12 with kernel-default-4.12.14-95.45.1.x86_64 and
>>> xen-4.11.3_02-2.20.1.x86_64
>>>
>>> The dump kernel doesn't star
On 03/02/2020 18:36, Hongyan Xia wrote:
> Rewrite the mapcache to be purely per-vCPU instead of partly per-vCPU
> and partly per-domain.
>
> This patch is needed to address performance issues when we start relying
> on the mapcache, e.g., when we do not have a direct map. Currently, the
> per-domai
On 04.02.20 15:07, Dietmar Hahn wrote:
Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
On 30/01/2020 13:03, Dietmar Hahn wrote:
Hi,
we use SLES12 with kernel-default-4.12.14-95.45.1.x86_64 and
xen-4.11.3_02-2.20.1.x86_64
The dump kernel doesn't start after "echo c > /proc/sy
flight 146712 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146712/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 146563
From: Jeff Kubascik
The Xen heap is split up into nodes and zones. Each node + zone is
managed as a separate pool of memory.
When returning pages to the heap, free_heap_pages will check adjacent
blocks to see if they can be combined into a larger block. However, the
zone of the adjacent block is
On Tuesday, February 4, 2020 9:30 AM, Stewart Hildebrand wrote:
>diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
>index 97902d42c1..7d39dd5be0 100644
>--- a/xen/common/page_alloc.c
>+++ b/xen/common/page_alloc.c
>@@ -1462,6 +1462,7 @@ static void free_heap_pages(
> if ( !
On Tue, 2020-02-04 at 14:00 +, Wei Liu wrote:
> On Mon, Feb 03, 2020 at 06:36:53PM +, Hongyan Xia wrote:
> [...]
> > diff --git a/xen/arch/x86/domain_page.c
> > b/xen/arch/x86/domain_page.c
> > index dd32712d2f..52971d2ecc 100644
> > --- a/xen/arch/x86/domain_page.c
> > +++ b/xen/arch/x86/d
flight 146725 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146725/
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
flight 146722 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 04.02.2020 14:51, Julien Grall wrote:
>
>
> On 04/02/2020 13:40, Jan Beulich wrote:
>> On 04.02.2020 14:33, Julien Grall wrote:
>>> At the moment, assign_pages() relies on PG_state_inuse to be 0. This
>>> makes the code slightly more difficult to understand.
>>
>> I can certainly see where you
From: Jeff Kubascik
The Xen heap is split up into nodes and zones. Each node + zone is
managed as a separate pool of memory.
When returning pages to the heap, free_heap_pages will check adjacent
blocks to see if they can be combined into a larger block. However, the
zone of the adjacent block is
Do not apply this patch - it is intended as a test case to show how the
problem presents itself. This was tested on a Xiling Zynq UltraScale+
MPSoC with CONFIG_DEBUG=y.
Add an assert for merging pages across zones
Revert "Check zone before merging adjacent blocks in heap"
Revert "xen/page_alloc:
On Tue, 2020-02-04 at 14:17 +, Andrew Cooper wrote:
> On 03/02/2020 18:36, Hongyan Xia wrote:
> > Rewrite the mapcache to be purely per-vCPU instead of partly per-
> > vCPU
> > and partly per-domain.
> >
> > This patch is needed to address performance issues when we start
> > relying
> > on th
A funeral for Lars Kurth will be held on Friday, 7 February, at 11:45am.
Everyone is welcome to attend. Location and further information here:
http://larskurth.muchloved.com
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
On 04.02.2020 16:14, Stewart Hildebrand wrote:
> From: Jeff Kubascik
>
> The Xen heap is split up into nodes and zones. Each node + zone is
> managed as a separate pool of memory.
>
> When returning pages to the heap, free_heap_pages will check adjacent
> blocks to see if they can be combined in
This patch sereis implements several important functionalities to run
Xen on top of Hyper-V. See individual patches for more details.
I've checked the assembly code as well as putting in a test patch to
make sure the hypercall interface is implemented correctly.
Wei.
Cc: Jan Beulich
Cc: Andrew
On Tuesday, February 4, 2020 10:22 AM, Jan Beulich wrote:
>On 04.02.2020 16:14, Stewart Hildebrand wrote:
>> From: Jeff Kubascik
>>
>> The Xen heap is split up into nodes and zones. Each node + zone is
>> managed as a separate pool of memory.
>>
>> When returning pages to the heap, free_heap_pages
On 2/4/20 3:22 PM, Jan Beulich wrote:
> On 04.02.2020 16:14, Stewart Hildebrand wrote:
>> From: Jeff Kubascik
>>
>> The Xen heap is split up into nodes and zones. Each node + zone is
>> managed as a separate pool of memory.
>>
>> When returning pages to the heap, free_heap_pages will check adjacen
Push hypervisor_ap_setup down to smp_callin.
Take the chance to replace xen_guest with cpu_has_hypervisor.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
xen/arch/x86/smpboot.c | 10 +++---
xen/include/asm-x86/guest/hypervisor.h | 2 +-
2
And implement the hook for Xen guest.
Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
---
v7:
1. Drop bogus ASSERT_UNREACHABLE from stub
2. Add Jan's Rb, considering #1 doesn't change the meat of the patch
---
xen/arch/x86/e820.c| 4 ++--
xen/arch/x86/guest/hypervisor.c
This allows us to set aside some address space for executable mapping.
This fixed map range starts from XEN_VIRT_END so that it is within reach
of the .text section.
Shift the percpu stub range and shrink livepatch range accordingly.
Signed-off-by: Wei Liu
---
v7:
1. Introduce ASM_CONSTANT
v6:
We want to be able to handle AP setup error in the upper layer.
For Xen, remove all panic() and BUG_ON() in init_evtchn and
map_vcpuinfo. Only panic/BUG_ON when Xen can't fail gracefully.
Signed-off-by: Wei Liu
---
v7:
1. Change init_evtchn
v6:
1. Change map_vcpuinfo as well
2. Make code shorte
VP assist page is rather important as we need to toggle some bits in it
for efficient nested virtualisation.
Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
Reviewed-by: Roger Pau Monné
---
v6:
1. Use hv_vp_assist_page_msr
2. Make code shorter
3. Preserve rsvdP fields
v5:
1. Deal with error p
Test if the infrastructure works.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
b/xen/arch/x86/guest/hyperv/hyperv.c
index 888bda25b0..2a2afcb363 100644
--- a/xen/arch/x86/gues
Hyper-V uses a technique called overlay page for its hypercall page. It
will insert a backing page to the guest when the hypercall functionality
is enabled. That means we can use a page that is not backed by real
memory for hypercall page.
To avoid shattering L0 superpages and treading on any MMIO
These functions will be used later to make hypercalls to Hyper-V.
Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
---
v7:
1. Use ASM_CONSTANT and put it in hyperv.c
v6:
1. Use asm(...) to generate symbol
2. Add a comment regarding volatile registers
v5:
1. Switch back to direct call
2. Fix so
This will be useful when invoking hypercall that targets specific
vcpu(s).
Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
---
v5:
1. Add Jan's Ack.
v4:
1. Use private.h
2. Add Paul's review tag
v2:
1. Fold into setup_pcpu_arg function
---
xen/arch/x86/guest/hyperv/hyp
Hyper-V's input / output argument must be 8 bytes aligned an not cross
page boundary. One way to satisfy those requirements is to use percpu
page.
For the foreseeable future we only need to provide input for TLB
and APIC hypercalls, so skip setting up an output page.
We will also need to provide
On 2/4/20 1:06 PM, Julien Grall wrote:
> Signed-off-by: Julien Grall
> Reviewed-by: Roger Pau Monné
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Igor Druzhinin (2):
x86/shim: suspend and resume platform time correctly
x86/time: report correct frequency of Xen PV clocksource
xen/arch/x86/pv/shim.c | 7 ++-
xen/arch/x86/time.c| 29 ++---
2 files changed, 16 insertions(+), 20 deletions(-)
--
2.7.4
___
Similarly to S3, platform time needs to be saved on guest suspend
and restored on resume respectively. This should account for expected
jumps in PV clock counter value after resume. time_suspend/resume()
are safe to use in PVH setting as is since any existing operations
with PIT that they do would
The value of the counter represents the number of nanoseconds
since host boot. That means the correct frequency is always 1GHz.
This inconsistency caused time to go slower in PV shim on most
platforms.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/time.c | 17 +
1 file changed,
flight 146715 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146715/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
test-amd64-i386-xl
On Tue, 2020-02-04 at 12:08 +, Wei Liu wrote:
> Thanks, I welcome effort to make Xen more scalable. :-)
>
> On Mon, Feb 03, 2020 at 06:36:53PM +, Hongyan Xia wrote:
> > Rewrite the mapcache to be purely per-vCPU instead of partly per-
> > vCPU
> > and partly per-domain.
> >
> > This patc
On Tue, Feb 04, 2020 at 03:36:55PM +, Wei Liu wrote:
> We want to be able to handle AP setup error in the upper layer.
>
> For Xen, remove all panic() and BUG_ON() in init_evtchn and
> map_vcpuinfo. Only panic/BUG_ON when Xen can't fail gracefully.
>
> Signed-off-by: Wei Liu
> ---
BTW I dis
flight 146727 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146727/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
From: Julien Grall
Signed-off-by: Julien Grall
---
xen/include/asm-x86/domain.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index a3ae5d9a20..f0c25ffec0 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/in
On 04/02/2020 16:53, Julien Grall wrote:
> From: Julien Grall
>
> Signed-off-by: Julien Grall
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Signed-off-by: Wei Liu
---
xen/arch/x86/e820.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index b9f589cac3..d67387f137 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -94,7 +94,7 @@ static void __init print_e820_memo
On Tue, Feb 04, 2020 at 04:48:05PM +, Wei Liu wrote:
> On Tue, Feb 04, 2020 at 03:36:55PM +, Wei Liu wrote:
> > We want to be able to handle AP setup error in the upper layer.
> >
> > For Xen, remove all panic() and BUG_ON() in init_evtchn and
> > map_vcpuinfo. Only panic/BUG_ON when Xen c
On 04/02/2020 16:55, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Tue, Feb 04, 2020 at 05:56:21PM +0100, Roger Pau Monné wrote:
> On Tue, Feb 04, 2020 at 04:48:05PM +, Wei Liu wrote:
> > On Tue, Feb 04, 2020 at 03:36:55PM +, Wei Liu wrote:
> > > We want to be able to handle AP setup error in the upper layer.
> > >
> > > For Xen, remove all panic() and
On 04.02.2020 17:55, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/e820.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> index b9f589cac3..d67387f137 100644
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.
On Tue, Feb 04, 2020 at 03:40:24PM +, Igor Druzhinin wrote:
> Similarly to S3, platform time needs to be saved on guest suspend
> and restored on resume respectively. This should account for expected
> jumps in PV clock counter value after resume. time_suspend/resume()
> are safe to use in PVH
On Tue, Feb 04, 2020 at 06:07:00PM +0100, Jan Beulich wrote:
> On 04.02.2020 17:55, Wei Liu wrote:
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/e820.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
> > index b9f589c
On Tue, Feb 04, 2020 at 03:40:25PM +, Igor Druzhinin wrote:
> The value of the counter represents the number of nanoseconds
> since host boot. That means the correct frequency is always 1GHz.
>
> This inconsistency caused time to go slower in PV shim on most
> platforms.
>
> Signed-off-by: Ig
Hello,
Current nested VMX code advertises support for the MSR bitmap feature,
yet the implementation isn't done. Previous to this series Xen just maps
the nested guest MSR bitmap (as set by L1) and that's it, the L2 guest
ends up using the L1 MSR bitmap.
This series adds handling of the L2 MSR bi
1 - 100 of 123 matches
Mail list logo
