On 2017-10-05 06:20 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 04, 2017 at 08:26:27PM +0200, Philipp Hahn wrote:
Hello,
Adding Ankur to this as I think he saw something similar.
But in the meantime - do you see this with the latest version of Linux?
with linux-4.9.52 running on Debian-Whe
On 2017-06-23 10:03 AM, Boris Ostrovsky wrote:
On 06/23/2017 12:54 PM, Olaf Hering wrote:
On Thu, Jun 22, Boris Ostrovsky wrote:
They are queued for 4.13.
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.13
This works for me. Thanks.
I assume there is no ready-to-pull
On 2017-06-23 10:03 AM, Boris Ostrovsky wrote:
On 06/23/2017 12:54 PM, Olaf Hering wrote:
On Thu, Jun 22, Boris Ostrovsky wrote:
They are queued for 4.13.
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.13
This works for me. Thanks.
I assume there is no ready-to-pull
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
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
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
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
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
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
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
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
14 matches
Mail list logo
