.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo
Move xen_platform_hvm() after xen_hvm_guest_late_init()
to avoid compile error.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
arch/x86/include/asm/x86_init.h | 2 ++
arch/x
On 2019/7/16 18:57, Juergen Gross wrote:
On 11.07.19 14:02, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch report warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Cc: Boris Ost
int3 doesn't generate
a gap, we can fix it by using int3 and drop useless xenint3.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Andrew Coop
On 2019/7/12 22:06, Andrew Cooper wrote:
On 11/07/2019 03:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in exception stack
which could be used for inserting call return address.
This gap is
On 2019/7/12 21:09, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 09:04:22PM +0800, Zhenzhong Duan wrote:
On 2019/7/12 20:06, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index
On 2019/7/12 20:06, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4722ba2..2138d69 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -596,7 +596,7
normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time. In this case, we
have to panic early if PVH is detected and nopv is enabled to avoid a
worse situation later.
Move xen_platform_hvm() after xen_hvm_guest_late_init() to avoid compile
error.
Sig
Clean up unnecessory code after that operation.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/xen
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellin
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch report warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
ber to
struct hypervisor_x86 set to true for those guest types and call
the detect functions only if nopv is false or ignore_nopv is true.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Jan Kiszk
e can fix it by using int3 and drop useless xenint3.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
v2: fix up description.
---
arch/x86/entry/en
Sorry for the noise, it looks description is wrong.
This is not a double pop, but xen pv taking the path
with create_gap=0, I'll send a v2.
Zhenzhong
On 2019/7/11 12:47, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") reveals
Fix it by removing xen_xenint3.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
arch/x86/include/asm/traps.h | 2 +-
arch/x86/xen/enlighten_pv.c | 2 +-
arch/x86/xen/xe
On 2019/7/9 22:54, Boris Ostrovsky wrote:
On 7/9/19 12:20 AM, Zhenzhong Duan wrote:
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
+static uint32_t __init xen_platform_hvm(void)
+{
+ uint32_t xen_domain = xen_cpuid_base();
+ struct x86_hyper_init *h
On 2019/7/8 21:46, Boris Ostrovsky wrote:
On 7/7/19 5:15 AM, Zhenzhong Duan wrote:
+static uint32_t __init xen_platform_hvm(void)
+{
+ if (xen_pv_domain())
+ return 0;
+
+ if (xen_pvh_domain() && nopv) {
+ /* Guest booting via the Xen-PVH bo
On 2019/7/5 21:06, Boris Ostrovsky wrote:
On 7/2/19 9:19 PM, Zhenzhong Duan wrote:
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it'
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellin
Clean up unnecessory code after that operation.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/xen
ber to
struct hypervisor_x86 set to true for those guest types and call
the detect functions only if nopv is false or ignore_nopv is true.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Jan Kiszk
normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time. In this case, we
have to panic early if PVH is detected and nopv is enabled to avoid a
worse situation later.
Move xen_platform_hvm() after xen_hvm_guest_late_init() to avoid compile
error.
Sig
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
ber to
struct hypervisor_x86 set to true for those guest types and call
the detect functions only if nopv is false or ignore_nopv is true.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Jan Kiszk
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellin
normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time.
To handle that case, add a new function xen_hvm_nopv_guest_late_init()
to detect PVH at a late time and panic itself if nopv enabled for a
PVH guest.
Signed-off-by: Zhenzhong Duan
Cc: Boris Os
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
Clean up unnecessory code after that operation.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/xen/enlighten_hvm.c
On 2019/7/3 2:13, Boris Ostrovsky wrote:
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in
kernel-parameters.txt
I am not sure we want patch #3, why not do everything in a single patch?
Thanks for review. I&
Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in
kernel-parameters.txt
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-g
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellin
normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time.
To handle that case, add a new function xen_hvm_nopv_guest_late_init()
to detect PVH at a late time and panic itself if 'nopv' enabled for a
PVH guest.
Signed-off-by: Zhenzhong Duan
Cc
here is already 'xen_nopv' parameter for XEN platform but not for
others. 'xen_nopv' can then be removed with this change.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc:
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
On 2019/7/2 11:48, Boris Ostrovsky wrote:
On Mon, Jul 01, 2019 at 10:20:27AM +0800, Zhenzhong Duan wrote:
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
R
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellin
normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time.
To handle that case, add a new function xen_hvm_nopv_guest_late_init()
to detect PVH at a late time and panic itself if 'nopv' enabled for a
PVH guest.
Signed-off-by: Zhenzhong Duan
Cc
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
here is already 'xen_nopv' parameter for XEN platform but not for
others. 'xen_nopv' can then be removed with this change.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc:
On 2019/6/25 20:31, Juergen Gross wrote:
On 24.06.19 14:02, Zhenzhong Duan wrote:
PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.
In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early
(),
xen_pvh_domain() could be used for that purpose.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/enlighten_hvm.c | 18 --
1
here is already 'xen_nopv' parameter for XEN platform but not for
others. 'xen_nopv' can then be removed with this change.
Suggested-by: Juergen Gross
Signed-off-by: Zhenzhong Duan
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Jan Kiszka
Cc: Boris Ost
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav
On 2019/6/24 21:18, Juergen Gross wrote:
On 23.06.19 15:01, Zhenzhong Duan wrote:
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Cc: xen-devel@lists.xenproject.org
---
Documentation/admin-guide/kernel-parameters.txt | 4
ar
at will do it.
There is already 'xen_nopv' parameter for XEN platform but not for
others. 'xen_nopv' can then be removed with this change.
Signed-off-by: Zhenzhong Duan
Cc: xen-devel@lists.xenproject.org
---
Documentation/admin-guide/kernel-parameters.txt | 4
ar
ninitialized in this
function
Signed-off-by: Zhenzhong Duan
I'm fine with the change, but going forward please be more specific
with your descriptions: Whether or not warnings get emitted for a
certain piece of code often highly depends on compiler version. Let
us know which version you'
Move reference of ol1e ahead or else we see below warning.
cc1: warnings being treated as errors
grant_table.c: In function 'replace_grant_pv_mapping':
grant_table.c:142: warning: 'ol1e.l1' may be used uninitialized in this function
Signed-off-by: Zhenzhong Duan
r
> more precisely not at all until Dom0 boot has progressed far
> enough) if the range(s) isn't/aren't marked reserved in E820.
>
> Signed-off-by: Zhenzhong Duan
> Tested-by: Gopalasetty, Manoj
> Reviewed-by: Roger Pau Monné
> ---
> xen/arch/x86/acpi/boot.c |
parse_dmar(), which
> 123c779379 ("VTd/dmar: Tweak how the DMAR table is clobbered")
> added several years later.
>
> Some stale comments are also removed, No functional change.
>
> Signed-off-by: Zhenzhong Duan
> ---
> v4: fixup description per Jan
>
>
在 2018/8/27 16:16, Jan Beulich 写道:
On 22.08.18 at 11:16, wrote:
Given what pt_pci_init() actually does, rename it properly and move its
declaration to pci.h, move the only call in acpi_mmcfg_init().
No functional change.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
Acked-by
Given what pt_pci_init() actually does, rename it properly and move its
declaration to pci.h, move the only call in acpi_mmcfg_init().
No functional change.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
Acked-by: Jan Beulich
---
xen/arch/x86/setup.c |2
all until Dom0 boot has progressed far
enough) if the range(s) isn't/aren't marked reserved in E820.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
Reviewed-by: Roger Pau Monné
---
xen/arch/x86/acpi/boot.c |2 ++
xen/arch/x86/setup.c |8 +++-
2 files c
在 2018/8/22 16:42, Roger Pau Monné 写道:
On Wed, Aug 22, 2018 at 04:39:05PM +0800, Zhenzhong Duan wrote:
在 2018/8/22 15:36, Roger Pau Monné 写道:
On Tue, Aug 21, 2018 at 09:53:08PM -0700, Zhenzhong Duan wrote:
pci_conf_read8() needs pci mmcfg mapping to work on multiple pci
segments system such
在 2018/8/22 15:36, Roger Pau Monné 写道:
On Tue, Aug 21, 2018 at 09:53:08PM -0700, Zhenzhong Duan wrote:
pci_conf_read8() needs pci mmcfg mapping to work on multiple pci
segments system such as HPE Superdome-Flex.
Move acpi_mmcfg_init() call in acpi_boot_init() before calling
acpi_parse_dmar
all until Dom0 boot has progressed far
enough) if the range(s) isn't/aren't marked reserved in E820.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
---
xen/arch/x86/acpi/boot.c |2 ++
xen/arch/x86/setup.c |8 +++-
2 files changed, 5 insertions(+), 5 deleti
l years later.
Some stale comments are also removed, No functional change.
Signed-off-by: Zhenzhong Duan
---
v4: fixup description per Jan
xen/arch/x86/tboot.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index d5a5292..
: Zhenzhong Duan
---
v3: fixup patch and description.
xen/arch/x86/tboot.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index d5a5292..1006f95 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -461,8 +461,6
DMAR table
> which
> is freed later.
>
> -v2: Add some description per Jan.
>
> Signed-off-by: Zhenzhong Duan
> ---
> xen/arch/x86/tboot.c |3 +--
> xen/drivers/passthrough/vtd/dmar.c |2 ++
> 2 files changed, 3 insertions(+), 2 deletions(-)
&g
l TXT heap table, fix the stale comments.
This is osmetic change, it's unnecessory to zap a copy of DMAR table which
is freed later.
-v2: Add some description per Jan.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/tboot.c |3 +--
xen/drivers/passthrough/vtd/dmar.c |
Release memory allocated for drhd iommu in error path.
-v2: fixup wrong parameter hiden due to my removing -Werror
Signed-off-by: Zhenzhong Duan
---
xen/drivers/passthrough/vtd/dmar.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b
On 2018/8/20 15:45, Jan Beulich wrote:
On 20.08.18 at 05:38, wrote:
On 2018/8/17 20:28, Jan Beulich wrote:
On 17.08.18 at 09:01, wrote:
pci_conf_read8() needs pci mmcfg mapping to work on multiple pci segments
system such as HPE Superdome-Flex.
Move acpi_mmcfg_init() call in acpi_boot_init(
On 2018/8/20 16:44, Andrew Cooper wrote:
On 20/08/2018 09:30, Jan Beulich wrote:
On 20.08.18 at 05:32, wrote:
When TBOOT enabled, acpi_parse_dmar() zap a copy of DMAR table rather
than the real table, so make it controled by config option based on the
fact that we already have done the real za
the stale comments.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/tboot.c |3 +--
xen/drivers/passthrough/vtd/dmar.c |2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
You've again failed to Cc maintainers (included now).
Jan
--- a/xen/arch/x86/tboot.c
+++
On 2018/8/17 20:28, Jan Beulich wrote:
On 17.08.18 at 09:01, wrote:
pci_conf_read8() needs pci mmcfg mapping to work on multiple pci segments
system such as HPE Superdome-Flex.
Move acpi_mmcfg_init() call in acpi_boot_init() before calling
acpi_parse_dmar() so that when pci_conf_read8() is cal
Release memory allocated for drhd iommu in error path.
Signed-off-by: Zhenzhong Duan
---
xen/drivers/passthrough/vtd/dmar.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 46decd4..8c5fa80
l TXT heap table, fix the stale comments.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/tboot.c |3 +--
xen/drivers/passthrough/vtd/dmar.c |2 ++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index d5a5292..f2
Given what pt_pci_init() actually does, rename it properly and move its
declaration to pci.h, move the only call in acpi_mmcfg_init().
No functional change.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
---
xen/arch/x86/setup.c |2 --
xen/arch/x86/x86_64
acpi_parse_one_drhd(), acpi_parse_one_rmrr()
and acpi_parse_one_atsr() all called acpi_parse_dev_scope() as their main
job. Splitting those functions to two pieces looks less optimal and meaningless.
Signed-off-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
---
xen/arch/x86/acpi/boot.c |2
在 2018/8/16 18:37, Jan Beulich 写道:
On 16.08.18 at 11:13, wrote:
On 2018/8/16 15:10, Jan Beulich wrote:
Have you investigated the alternative of deferring acpi_dmar_init()
to a later point, or at least the part of it that needs to do PCI
config space accesses? I'm not currently convinced the de
在 2018/8/16 18:42, Jan Beulich 写道:
On 16.08.18 at 11:30, wrote:
On 2018/8/16 17:13, Zhenzhong Duan wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long
mbi_p)
generic_apic_probe();
+pt_pci_init
On 2018/8/16 17:13, Zhenzhong Duan wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long
mbi_p)
generic_apic_probe();
+ pt_pci_init();
+
+ acpi_mmcfg_init();
+
acpi_boot_init();
With the
On 2018/8/16 15:10, Jan Beulich wrote:
On 16.08.18 at 07:10, wrote:
On a multiple pci segment system such as HPE Superdome-Flex, pci config space
from nonzero segment is accessed with mmcfg during acpi parsing DMAR region.
First of all - can you please write a little more helpful (to reviewer
No functional change.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/x86_64/mmconfig-shared.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c
b/xen/arch/x86/x86_64/mmconfig-shared.c
index 7c3b7fd..4a6ca26 100644
--- a/xen/arch/x86
ff-by: Zhenzhong Duan
Tested-by: Gopalasetty, Manoj
---
xen/arch/x86/setup.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8301de8..9af7426 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1493,6 +14
在 2018/7/20 18:13, Andrew Cooper 写道:
On 20/07/18 11:13, Roger Pau Monné wrote:
On Fri, Jul 20, 2018 at 02:29:34AM -0700, Zhenzhong Duan wrote:
No functional change.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/irq.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
No functional change.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/irq.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 87ef2e8..5253fd1 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2701,8 +2701,6 @@ int
On 2018/3/27 16:52, Jan Beulich wrote:
On 27.03.18 at 06:52, wrote:
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20
On 2018/3/28 13:52, Jan Beulich write:
Zhenzhong Duan 03/28/18 4:03 AM >>>
When ALTERNATIVE_2 is used, we see below error during build.
"error: macro "as_max" requires 2 arguments, but only 1 given"
Signed-off-by: Zhenzhong Duan
See "[PATCH v2 2/6] x86:
When ALTERNATIVE_2 is used, we see below error during build.
"error: macro "as_max" requires 2 arguments, but only 1 given"
Signed-off-by: Zhenzhong Duan
---
xen/include/asm-x86/alternative.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a
On 2018/3/27 16:52, Jan Beulich wrote:
On 27.03.18 at 06:52, wrote:
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20
ion from sibling threads.
v2: Use (system_state < SYS_STATE_active) to initialize use_shadow_spec_ctrl
instead of literal 1 per Jan.
Signed-off-by: Zhenzhong Duan
---
xen/include/asm-x86/spec_ctrl.h | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/xen/incl
在 2018/3/26 21:39, Jan Beulich 写道:
On 21.03.18 at 03:58, wrote:
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20 vcpu
izing use_shadow_spec_ctrl with 1, IBRS is disabled in intr/nmi exit
path at bootup stage. Then delay in construct_dom0 is ~50s.
Signed-off-by: Zhenzhong Duan
---
xen/include/asm-x86/spec_ctrl.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/xen/include/asm-x86/spec_ctr
在 2018/2/14 17:58, Jan Beulich 写道:
On 14.02.18 at 10:25, wrote:
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -269,28 +269,29 @@
* This is logical merge of DO_OVERWRITE_RSB and DO_SPEC_CTRL_ENTRY
* maybexen=1, but with conditionals rather than alte
happend to cover the bug in certain case so
we didn't reproduce without bti=0. Change to use %edx.
Also drop an unused label per Jan.
Reported-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
Signed-off-by: Jan Beulich
---
xen/include/asm-x86/spec_ctrl_asm.h |9 +
1 files change
fore wrmsr.
DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
we didn't reproduce without bti=0.
Signed-off-by: Zhenzhong Duan
Re-do actual code change. Also drop an unused label.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/
cleared to zero before wrmsr.
DO_OVERWRITE_RSB clobbers %eax and happend to cover the bug in certain case so
we didn't reproduce without bti=0. Change to use %edx.
Reviewed-by: Boris Ostrovsky
Tested-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
Two formal things: Please put tags in
happend to cover the bug in certain case so
we didn't reproduce without bti=0. Change to use %edx.
Reviewed-by: Boris Ostrovsky
Tested-by: Boris Ostrovsky
Signed-off-by: Zhenzhong Duan
---
xen/include/asm-x86/spec_ctrl_asm.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
d
在 2018/2/6 19:56, Andrew Cooper 写道:
On 06/02/18 11:41, Zhenzhong Duan wrote:
On 2018/2/6 18:50, Andrew Cooper wrote:
On 06/02/18 10:29, zhenzhong.duan wrote:
2018年2月6日 17:20于 Andrew Cooper <mailto:andrew.coop...@citrix.com>>写道：
>
> On 06/02/2018 09:13, Zhenzhong Duan wrote:
On 2018/2/6 18:50, Andrew Cooper wrote:
On 06/02/18 10:29, zhenzhong.duan wrote:
2018年2月6日 17:20于 Andrew Cooper <mailto:andrew.coop...@citrix.com>>写道：
>
> On 06/02/2018 09:13, Zhenzhong Duan wrote:
> > 在 2018/2/6 16:59, Andrew Cooper 写道:
> >> On 06/02/20
在 2018/2/6 16:59, Andrew Cooper 写道:
On 06/02/2018 08:43, Zhenzhong Duan wrote:
When ( ibrs && thunk == THUNK_DEFAULT && !retpoline_safe() ) is true,
thunk is set to THUNK_JMP rather than THUNK_RETPOLINE.
When (!ibrs && thunk == THUNK_DEFAULT && !retpoline_sa
When ( ibrs && thunk == THUNK_DEFAULT && !retpoline_safe() ) is true,
thunk is set to THUNK_JMP rather than THUNK_RETPOLINE.
When (!ibrs && thunk == THUNK_DEFAULT && !retpoline_safe() ) is true,
we should do the same.
Signed-off-by: Zhenzhong Duan
---
xen/arc
96 matches
Mail list logo
