Steven Rostedt writes:
> On Tue, 7 Nov 2023 13:56:53 -0800
> Ankur Arora wrote:
>
>> This reverts commit e3ff7c609f39671d1aaff4fb4a8594e14f3e03f8.
>>
>> Note that removing this commit reintroduces "live patches failing to
>> complete within a reas
Josh Poimboeuf writes:
> On Thu, Nov 09, 2023 at 12:31:47PM -0500, Steven Rostedt wrote:
>> On Thu, 9 Nov 2023 09:26:37 -0800
>> Josh Poimboeuf wrote:
>>
>> > On Tue, Nov 07, 2023 at 06:16:09PM -0500, Steven Rostedt wrote:
>> > > On Tue, 7 Nov 202
Josh Poimboeuf writes:
> On Thu, Nov 09, 2023 at 02:50:48PM -0800, Ankur Arora wrote:
>> >> I guess I'm not fully understanding what the cond rescheds are for. But
>> >> would an IPI to all CPUs setting NEED_RESCHED, fix it?
>>
>> Yeah. We could just
ller sees
more faults until the remap is done.
[1] https://lore.kernel.org/linux-mm/20181105145141.6f993...@w520.home/
Signed-off-by: Ankur Arora
---
drivers/vfio/pci/vfio_pci.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vf
On 2020-12-08 8:08 a.m., David Woodhouse wrote:
On Wed, 2020-12-02 at 19:02 +, David Woodhouse wrote:
I feel we could just accommodate it as subtype in
KVM_XEN_ATTR_TYPE_CALLBACK_VIA.
Don't see the adavantage in having another xen attr type.
Yeah, fair enough.
But kinda have mixed fee
On 2020-12-01 5:07 a.m., David Woodhouse wrote:
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
+static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
+{
+ struct shared_info *shared_info;
+ struct page *page;
+
+ page = gfn_to_page(kvm, gfn);
+ if (is_er
On 2020-12-01 1:48 a.m., David Woodhouse wrote:
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
Add a new exit reason for emulator to handle Xen hypercalls.
Albeit these are injected only if guest has initialized the Xen
hypercall page
I've reworked this a little.
I didn't like the inc
On 2020-12-01 5:26 p.m., David Woodhouse wrote
On Tue, 2020-12-01 at 16:40 -0800, Ankur Arora wrote:
On 2020-12-01 5:07 a.m., David Woodhouse wrote:
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
+static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
+{
+ struct
On 2020-12-02 12:03 a.m., David Woodhouse wrote:
On Tue, 2020-12-01 at 21:19 -0800, Ankur Arora wrote:
+ for (i = 0; i < PAGE_SIZE / sizeof(instructions); i++) {
+ *(u32 *)&instructions[1] = i;
+ if (kvm_vcpu_write_gue
On 2020-12-02 4:20 a.m., David Woodhouse wrote:
On Wed, 2020-12-02 at 10:44 +, Joao Martins wrote:
[late response - was on holiday yesterday]
On 12/2/20 12:40 AM, Ankur Arora wrote:
On 2020-12-01 5:07 a.m., David Woodhouse wrote:
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote
On 2020-12-02 2:44 a.m., Joao Martins wrote:
[late response - was on holiday yesterday]
On 12/2/20 12:40 AM, Ankur Arora wrote:
On 2020-12-01 5:07 a.m., David Woodhouse wrote:
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
+static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t
On 2020-12-02 11:02 a.m., David Woodhouse wrote:
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote:
On 12/2/20 4:47 PM, David Woodhouse wrote:
On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
On 12/2/20 11:17 AM, David Woodhouse wrote:
I might be more inclined to go for a model wher
calls to io_remap_pfn_range() if the VMA is already
mapped.
Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access
on disabled memory")
Signed-off-by: Ankur Arora
---
drivers/vfio/pci/vfio_pci.c | 48 ++---
drivers/vfio/pci/vfio_
On 2021-03-02 4:47 a.m., Bharat Bhushan wrote:
Hi Ankur,
-Original Message-
From: Ankur Arora
Sent: Friday, February 26, 2021 6:24 AM
To: Bharat Bhushan
Cc: alex.william...@redhat.com; ankur.a.ar...@oracle.com; linux-
ker...@vger.kernel.org; Sunil Kovvuri Goutham ;
termi...@gmail.com
's what my fix addressed as well.
While article https://lwn.net/Articles/828536/ suggest that you have already
faced and fixed this issue
"- vfio-pci: protect remap_pfn_range() from simultaneous calls (Ankur
Arora) [Orabug: 31663628] {CVE-2020-12888} {CVE-2020-12888}"
B
On 2/20/19 1:09 PM, Paolo Bonzini wrote:
On 20/02/19 21:15, Joao Martins wrote:
2. PV Driver support (patches 17 - 39)
We start by redirecting hypercalls from the backend to routines
which emulate the behaviour that PV backends expect i.e. grant
table and interdomain events. Next, we ad
On 2/20/19 3:39 PM, Marek Marczykowski-Górecki wrote:
On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote:
2. PV Driver support (patches 17 - 39)
We start by redirecting hypercalls from the backend to routines
which emulate the behaviour that PV backends expect i.e. grant
ta
useful for local xenhosts
(type xenhost_r0) because unlike Xen, where there is an external
hypervisor which can change the memory underneath a GFN, that is not
possible when the hypervisor is running in the same address space
as the entity doing the ballooning.
Co-developed-by: Ankur Arora
Signed
Mechanical changes, now most of these calls take xenhost_t *
as parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
---
drivers/xen/cpu_hotplug.c | 14 ++---
drivers/xen/gntalloc.c| 13
drivers/xen/gntdev.c | 16 +++
drivers
For the most part, we now pass xenhost_t * as a parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
---
drivers/block/xen-blkback/blkback.c | 34 +
drivers/block/xen-blkback/common.h | 2 +-
drivers/block/xen-blkback/xenbus.c | 63 -
drivers/block
Make hypercall_page a generic interface which can be implemented
by other hypervisors. With this change, hypercall_page now points to
the newly introduced xen_hypercall_page which is seeded by Xen, or
to one that is filled in by a different hypervisor.
Signed-off-by: Ankur Arora
---
arch/x86
rtins
Signed-off-by: Ankur Arora
---
drivers/block/xen-blkback/blkback.c | 14 +-
drivers/xen/gntdev.c| 2 +-
drivers/xen/grant-table.c | 20 ++--
include/xen/grant_table.h | 11 ++-
4 files changed, 38 insertions(+), 9 dele
xen_cpuid_base() is used to probe and setup features early in a
guest's lifetime.
We want this to behave differently depending on xenhost->type: for
instance, local xenhosts cannot intercept the cpuid instruction at all.
Add op (*cpuid_base)() in xenhost_ops_t.
Signed-off-by: Ank
eant to get feedback before
proceeding further. Also note that the FIFO logic and some Xen drivers
(input, pciback, scsi etc) are mostly unchanged, so will not build.
Please take a look.
Thanks
Ankur
Ankur Arora (16):
x86/xen: add xenhost_t interface
x86/xen: cpuid support in xenhost_
visibility
into related events/hypercalls in the default hypervisor.
TODO:
- percpu data structures for xen_vcpu
Signed-off-by: Ankur Arora
---
arch/x86/xen/enlighten.c | 93 +---
arch/x86/xen/enlighten_hvm.c | 87 ++
arch/x86
the IF flag
maps onto the xh_default->vcpu_info->evtchn_upcall_mask.
However, we still update the xh_remote->vcpu_info->evtchn_upcall_mask
on a best effort basis to minimize unnecessary work in remote xenhost.
TODO:
- direct pv_ops.irq are disabled.
Signed-off-by: Ankur Arora
---
this
event handling is largley unchanged.
Note that the IPI, timer, VIRQ, FUNCTION, PMU etc vectors remain
attached to xh_default. Only interdomain evtchns are allowable as
xh_remote.
TODO:
- to minimize the changes, evtchn FIFO is disabled for now.
Signed-off-by: Ankur Arora
---
arch/x8
rest of patch is just changing the interfaces where needed.
Signed-off-by: Ankur Arora
---
drivers/block/xen-blkback/blkback.c| 10 +-
drivers/net/xen-netfront.c | 14 +-
drivers/pci/xen-pcifront.c | 4 +-
drivers/xen/cpu_hotplug.c | 4
state. For both of those, remote xenhost is not
of interest so we only use the default xenhost.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/xen/hypervisor.h | 1 -
arch/x86/xen/enlighten.c | 10 ++-
arch/x86/xen/enlighten_hvm.c | 38
.
Also add xenhost_register() and stub registration in the various guest
types.
Signed-off-by: Ankur Arora
---
arch/x86/xen/Makefile| 1 +
arch/x86/xen/enlighten_hvm.c | 13 +
arch/x86/xen/enlighten_pv.c | 16 ++
arch/x86/xen/enlighten_pvh.c | 12 +
arch/x86/xen/xenhost.c
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize both.
Signed-off-by: Ankur Arora
---
arch/x86/xen/grant-table.c | 71 +++--
driver
the
right thing.
TODO:
- Multicalls for now assume the default xenhost
- xen_hypercall_* symbols are only generated for the default xenhost.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/xen/hypercall.h | 233 ++-
arch/x86/xen/enlighten.c | 3
because we do feature
validation early which guarantees that the features of interest are
compatible. Features not of interest, are related to MMU, clock, pirq, etc where
the interface to L0-Xen should not matter.
Signed-off-by: Ankur Arora
---
arch/x86/xen/enlighten_hvm.c | 15
On 6/17/19 2:28 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Xen ballooning uses hollow struct pages (with the underlying GFNs being
populated/unpopulated via hypercalls) which are used by the grant logic
to map grants from other domains.
This patch allows the default
On 6/17/19 2:36 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize
On 6/17/19 2:50 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
As part of xenbus init, both frontend, backend interfaces need to talk
on the correct xenbus. This might be a local xenstore (backend) or might
be a XS_PV/XS_HVM interface (frontend) which needs to talk over
On 6/17/19 3:07 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Mechanical changes, now most of these calls take xenhost_t *
as parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
---
drivers/xen/cpu_hotplug.c | 14 ++---
drivers/xen/gntalloc.c
On 6/17/19 3:55 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Xenhost type xenhost_r0 does not support standard GNTTABOP_map_grant_ref
semantics (map a gref onto a specified host_addr). That's because
since the hypervisor is local (same address space as the call
On 6/17/19 3:14 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
For the most part, we now pass xenhost_t * as a parameter.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
I don't see how this can be a patch on its own.
Yes, the reason this was separate was
On 2019-06-07 8:04 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Add xenhost_t which will serve as an abstraction over Xen interfaces.
It co-exists with the PV/HVM/PVH abstractions (x86_init, hypervisor_x86,
pv_ops etc) and is meant to capture mechanisms for communication
On 2019-06-07 8:08 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
HYPERVISOR_shared_info is used for irq/evtchn communication between the
guest and the host. Abstract out the setup/reset in xenhost_t such that
nested configurations can use both xenhosts simultaneously.
I
On 2019-06-07 7:51 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Hi all,
This is an RFC for xenhost support, outlined here by Juergen here:
https://lkml.org/lkml/2019/4/8/67.
First: thanks for all the effort you've put into this series!
The high level idea is to pr
On 2019-06-07 9:21 a.m., Juergen Gross wrote:
On 07.06.19 17:22, Joao Martins wrote:
On 6/7/19 3:51 PM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Hi all,
This is an RFC for xenhost support, outlined here by Juergen here:
https://lkml.org/lkml/2019/4/8/67.
First: thanks for
On 2019-06-26 12:23 p.m., Thomas Gleixner wrote:
On Wed, 26 Jun 2019, Raslan, KarimAllah wrote:
On Wed, 2019-06-26 at 10:54 -0400, Konrad Rzeszutek Wilk wrote:
There were some ideas that Ankur (CC-ed) mentioned to me of using the perf
counters (in the host) to sample the guest and construct a b
On 7/9/19 5:38 AM, Peter Zijlstra wrote:
On Mon, Jul 08, 2019 at 07:00:08PM -0700, Ankur Arora wrote:
On 2019-06-26 12:23 p.m., Thomas Gleixner wrote:
On Wed, 26 Jun 2019, Raslan, KarimAllah wrote:
On Wed, 2019-06-26 at 10:54 -0400, Konrad Rzeszutek Wilk wrote:
There were some ideas that
Replace hard coded "ACPI0007" with ACPI_PROCESSOR_DEVICE_HID
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Ankur Arora
---
drivers/xen/xen-acpi-processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xe
-back on more limited P and C states.
Tested C-state upload via mwait_idle=0.
Changes in v2:
- rebased to 4.11.0-rc2
- addressed comments from Boris Ostrovsky
Ankur Arora (2):
xen/acpi: Replace hard coded "ACPI0007"
xen/acpi: upload PM state from init-domain to Xen
drivers/xe
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Ankur Arora
---
drivers/xen/xen-acpi-processor.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
index fac0d7b..23e391d 100644
On 2017-03-22 02:05 AM, Stanislaw Gruszka wrote:
On Tue, Mar 21, 2017 at 03:43:38PM -0700, Ankur Arora wrote:
This was broken in commit cd979883b9ede90643e019f33cb317933eb867b4.
do_suspend (from xen/manage.c) and thus xen_resume_notifier never get
called on the initial-domain at resume (it is
/20200316101856.gh11...@dhcp22.suse.cz/#t)
Accordingly this series enables X86_FEATURE_NT_GOOD for Intel Broadwellx
and AMD Rome. (In my testing, the performance was also good for some
pre-production models but this series leaves them out.)
Please review.
Thanks
Ankur
Ankur Arora (8):
Add a MOVNTI based implementation of memset().
memset_orig() and memset_movnti() only differ in the opcode used in the
inner loop, so move the memset_orig() logic into a macro, which gets
expanded into memset_movq() and memset_movnti().
Signed-off-by: Ankur Arora
---
arch/x86/lib/memset_64.S
rface clear_user_highpage_uncached().
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/page.h| 6 ++
arch/x86/include/asm/page_32.h | 9 +
arch/x86/include/asm/page_64.h | 14 ++
include/asm-generic/page.h | 3 +++
include/linux/highmem.h| 10 ++
5
4.221784 GB/sec
# Copying 32MB bytes ...
14.293337 GB/sec
# Copying 128MB bytes ...
15.238947 GB/sec
# Copying 512MB bytes ...
16.476093 GB/sec
Signed-off-by: Ankur Arora
---
tools/arch/x86/lib/memset_64.S | 68
tools/perf/ben
.002 K/sec
( +- 47.82% ) (11.75%)
3.37465 +- 0.00474 seconds time elapsed ( +- 0.14% )
The L1-dcache-load-misses (L1D.REPLACEMENT) count is much lower just
like the previous two cases. No performance improvement for Skylakex
though.
Signed-off-by: Ankur Arora
---
a MOVNTI loop.
The page-clearing BW is substantially higher (~100% or more), so enable
X86_FEATURE_NT_GOOD for Intel Broadwellx.
Signed-off-by: Ankur Arora
---
arch/x86/kernel/cpu/intel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/in
Enabled on microarchitectures with performant non-temporal MOV (MOVNTI)
instruction.
Signed-off-by: Ankur Arora
---
arch/x86/include/asm/cpufeatures.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 7b0afd5e6c57
27;perf bench memset' comparison on AMD Naples (AMD EPYC 7551) shows
similar performance gains. So, enable X86_FEATURE_NT_GOOD for
AMD Zen.
Signed-off-by: Ankur Arora
---
arch/x86/kernel/cpu/amd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/
pages.
Signed-off-by: Ankur Arora
---
mm/memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index eeae590e526a..4d2c58f83ab1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5092,7 +5092,7 @@ static void clear_gigantic_page(struct page
On 2020-10-14 8:28 a.m., Ingo Molnar wrote:
* Ankur Arora wrote:
Uncached writes are suitable for circumstances where the region written to
is not expected to be read again soon, or the region written to is large
enough that there's no expectation that we will find the writes in the
On 2020-10-14 8:31 a.m., Ingo Molnar wrote:
* Ankur Arora wrote:
System: Oracle X6-2
CPU: 2 nodes * 10 cores/node * 2 threads/core
Intel Xeon E5-2630 v4 (Broadwellx, 6:79:1)
Memory: 256 GB evenly split between nodes
Microcode
On 2020-10-14 8:45 a.m., Andy Lutomirski wrote:
On Wed, Oct 14, 2020 at 1:33 AM Ankur Arora wrote:
Define clear_page_uncached() as an alternative_call() to clear_page_nt()
if the CPU sets X86_FEATURE_NT_GOOD and fallback to clear_page() if it
doesn't.
Similarly d
On 2020-10-14 12:56 p.m., Borislav Petkov wrote:
On Wed, Oct 14, 2020 at 01:32:55AM -0700, Ankur Arora wrote:
This can potentially improve page-clearing bandwidth (see below for
performance numbers for two microarchitectures where it helps and one
where it doesn't) and can help indirect
On 2020-10-14 2:07 p.m., Andy Lutomirski wrote:
On Oct 14, 2020, at 12:58 PM, Borislav Petkov wrote:
On Wed, Oct 14, 2020 at 08:45:37AM -0700, Andy Lutomirski wrote:
On Wed, Oct 14, 2020 at 1:33 AM Ankur Arora wrote:
Define clear_page_uncached() as an alternative_call() to
On 2020-10-14 2:12 p.m., Borislav Petkov wrote:
On Wed, Oct 14, 2020 at 02:07:30PM -0700, Andy Lutomirski wrote:
I assume it’s for a little optimization of clearing more than one
page per SFENCE.
In any event, based on the benchmark data upthread, we only want to do
NT clears when they’re rathe
On 2020-10-15 3:35 a.m., Borislav Petkov wrote:
On Wed, Oct 14, 2020 at 08:37:44PM -0700, Ankur Arora wrote:
I don't disagree but I think the selection of cached/uncached route should
be made where we have enough context available to be able to choose to do
this.
This could be for ex
On 2020-10-15 3:40 a.m., Borislav Petkov wrote:
On Wed, Oct 14, 2020 at 08:21:57PM -0700, Ankur Arora wrote:
Also, if we did extend clear_page() to take the page-size as parameter
we still might not have enough information (ex. a 4K or a 2MB page that
clear_page() sees could be part of a GUP of
On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
Certain workloads perform poorly on KVM compared to baremetal
due to baremetal's ability to perform mwait on NEED_RESCHED
bit of task fla
On 2019-05-15 6:07 p.m., Wanpeng Li wrote:
On Thu, 16 May 2019 at 02:42, Ankur Arora wrote:
On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
Certain workloads perform poorly on KVM
On 2019-05-15 1:43 p.m., Marcelo Tosatti wrote:
On Wed, May 15, 2019 at 11:42:56AM -0700, Ankur Arora wrote:
On 5/14/19 6:50 AM, Marcelo Tosatti wrote:
On Mon, May 13, 2019 at 05:20:37PM +0800, Wanpeng Li wrote:
On Wed, 8 May 2019 at 02:57, Marcelo Tosatti wrote:
Certain workloads perform
On 2019-06-12 2:15 p.m., Andrew Cooper wrote:
On 09/05/2019 18:25, Ankur Arora wrote:
Allow for different hypercall implementations for different xenhost types.
Nested xenhost, which has two underlying xenhosts, can use both
simultaneously.
The hypercall macros (HYPERVISOR_*) implicitly use
On 2019-06-14 5:04 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical patch that adds a new param, xenhost_t * to the
evtchn interfaces. The evtchn port instead of being domain unique, is
now scoped to xenhost_t.
As part of upcall handling we now look at all
On 2019-06-14 4:53 a.m., Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Abstract out xen_vcpu_id probing via (*probe_vcpu_id)(). Once that is
availab,e the vcpu_info registration happens via the VCPUOP hypercall.
Note that for the nested case, there are two vcpu_ids, and two
On 2017-06-08 03:53 PM, Konrad Rzeszutek Wilk wrote:
On Thu, Jun 08, 2017 at 10:28:15AM +0200, Juergen Gross wrote:
On 03/06/17 02:05, Ankur Arora wrote:
This patch series fixes a bunch of issues in the xen_vcpu setup
logic.
Simplify xen_vcpu related code: code refactoring in advance of the
en_pv.c to enlighten.c.
xen_vcpu_info_reset(): pulls together all the code where xen_vcpu
is set to default.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Ankur Arora
---
arch/x86/xen/enlighten.c | 101 +++
arch/x86/xen/enlighten_hvm.c | 6 +--
ar
e.
As most of this dance code is done already in xen_vcpu_restore()
let's make it callable on PV, PVH and PVHVM.
Based-on-patch-by: Konrad Wilk
Reviewed-by: Boris Ostrovsky
Signed-off-by: Ankur Arora
---
arch/x86/xen/enlighten.c | 45 +++-
arc
strovsky
Signed-off-by: Ankur Arora
---
arch/x86/xen/enlighten.c | 46 +---
arch/x86/xen/enlighten_hvm.c | 9 +
arch/x86/xen/enlighten_pv.c | 14 +-
arch/x86/xen/xen-ops.h | 2 +-
4 files changed, 45 insertions(+), 26 d
hen there
are > MAX_VIRT_CPUS threads going into stop_machine() but coming
back up there's valid state for only the first MAX_VIRT_CPUS.
This patch pulls the excess CPUs down via cpu_down().
Reviewed-by: Boris Ostrovsky
Signed-off-by: Ankur Arora
---
arch/x86/xen/smp
Handle xen_vcpu_setup() failure at boot: pull CPUs (> MAX_VIRT_CPUS)
down if we fall back to xen_have_vcpu_info_placement = 0.
Tested with various combinations of PV/PVHv2/PVHVM save/restore
and cpu-hotadd-hotremove. Also tested by simulating failure in
VCPUOP_register_vcpu_info.
Please revie
problematically, this means we call xen_vcpu_setup()
twice at restore -- once from the vcpu info placement call and the
second time from xen_vcpu_restore().
Fix by calling xen_setup_vcpu_info_placement() at boot only.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Ankur Arora
---
arch/x86/xen
79 matches
Mail list logo
