Am Dienstag, 4. Februar 2020, 15:12:28 CET schrieb Igor Druzhinin:
> 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
On 2/4/20 10:28 AM, Santucco wrote:
> 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.
Ok, yet another test to localize the problem.
Could you please
flight 146736 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146736/
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
flight 146734 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146734/
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
flight 146730 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146730/
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
flight 146731 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146731/
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
flight 146728 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146728/
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
flight 146726 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146726/
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.
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| 17 +++--
2 files changed, 17 insertions(+), 7 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/HPET that they do
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 | 5 ++---
1 file changed, 2
On 04/02/2020 17:43, Igor Druzhinin wrote:
> On 04/02/2020 17:17, Roger Pau Monné wrote:
>> 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
On 04/02/2020 17:28, Roger Pau Monné wrote:
> 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
It turns out that a bug (since forever) in Xen causes XSAVE records to have
non-architectural behaviour on xsave-capable hardware, when a PV guest has not
touched the state.
In such a case, the data record returned from Xen is 2*uint64_t, both claiming
the (illegitimate) state of %xcr0 and
Per the ARM Generic Interrupt Controller Architecture Specification (ARM
IHI 0069E), reserved registers should generally be treated as RAZ/WI.
To simplify the VGICv3 design and improve guest compatibility, treat the
default case for GICD and GICR registers as read_as_zero/write_ignore.
> But the problem I'm worried about is this:
>
> Scenario B
> 1. Make an empty, uninitialized structure, without calling NewType()
> 2. Fill in some fields
> 3. Marshal it into json
> 4. Marshal it out of json (with the same version)
>
> In the case above, step 3 encodes all the known fields with
Hey Julien,
On 2/1/2020 6:45 AM, Julien Grall wrote:
> Hi,
>
> On 31/01/2020 20:10, Jeff Kubascik wrote:
>> Per the ARM Generic Interrupt Controller Architecture Specification (ARM
>> IHI 0069E), reserved registers should generally be treated as RAZ/WI.
>> To simplify the VGICv3 design and
flight 146729 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146729/
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
flight 146723 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146723/
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
On 04/02/2020 17:17, Roger Pau Monné wrote:
> 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
Current implementation of nested VMX has a half baked handling of MSR
bitmaps for the L1 VMM: it maps the L1 VMM provided MSR bitmap, but
doesn't actually load it into the nested vmcs, and thus the nested
guest vmcs ends up using the same MSR bitmap as the L1 VMM.
This is wrong as there's no
Nested VMX doesn't expose support for
SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE,
SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY or
SECONDARY_EXEC_APIC_REGISTER_VIRT, and hence the x2APIC MSRs should
always be trapped in the nested guest MSR bitmap, or else a nested
guest could access the hardware x2APIC MSRs
Import the functions and it's dependencies. Based on Linux 5.5, commit
id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
Signed-off-by: Roger Pau Monné
---
xen/common/bitmap.c | 41
xen/include/asm-x86/bitops.h | 2 ++
xen/include/xen/bitmap.h | 38
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
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:
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
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 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
> +++
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()
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 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
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
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
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
+++
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
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
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
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
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
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
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
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
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
---
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
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
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
---
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
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
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:
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 +-
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,
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
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 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
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
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
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
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
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
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
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
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
> > +++
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 (
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
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.
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 >
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
>
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
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 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
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 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
> @@
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
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
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:
> -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]
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
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
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
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
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
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
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 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
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
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
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()
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
> > >
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
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);
>>>
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
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, 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
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 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 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
^
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 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
1 - 100 of 123 matches
Mail list logo
