From: Bharat Bhushan r65...@freescale.com
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
Signed-off-by: Alexander Graf ag...@suse.de
---
arch
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, October 04, 2013 4:46 PM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall
: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On 04.10.2013, at 06:26, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, October 03, 2013 12:04 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm
).
Please describe which stub you are talking about.
kvm_hypercall is always available, regardless of the config option, which
makes
all its subfunctions always available as well.
This patch renames kvm_hypercall() to epapr_hypercall() and which is always
available. And the kvm_hypercall
with
generic epapr bits (which your patches already do).
Please describe which stub you are talking about.
kvm_hypercall is always available, regardless of the config option, which
makes
all its subfunctions always available as well.
This patch renames kvm_hypercall() to epapr_hypercall
] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On 07.10.2013, at 17:43, Bhushan Bharat-R65777 r65...@freescale.com wrote:
at least when I can avoid it. With the current code the
compiler would be
smart enough to just optimize out the complete branch.
Sure. My point
-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On 07.10.2013, at 17:43, Bhushan Bharat-R65777 r65...@freescale.com wrote:
at least when I can avoid it. With the current code the
compiler would be
smart
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, October 07, 2013 9:43 PM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2
- epapr_hypercall() is always defined and returns EV_UNIMPLEMENTED
when
On Mon, 2013-10-07 at 22:23 +0530, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2
- epapr_hypercall
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- CONFIG_KVM_GUEST implies CONFIG_EPAPR_PARAVIRT, so using only
CONFIG_EPAPR_PARAVIRT
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, October 04, 2013 4:46 PM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On 04.10.2013, at 06:26, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, October 03, 2013 12:04 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-ppc
).
Please describe which stub you are talking about.
kvm_hypercall is always available, regardless of the config option, which
makes
all its subfunctions always available as well.
This patch renames kvm_hypercall() to epapr_hypercall() and which is always
available. And the kvm_hypercall
with
generic epapr bits (which your patches already do).
Please describe which stub you are talking about.
kvm_hypercall is always available, regardless of the config option, which
makes
all its subfunctions always available as well.
This patch renames kvm_hypercall() to epapr_hypercall
] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On 07.10.2013, at 17:43, Bhushan Bharat-R65777 r65...@freescale.com wrote:
at least when I can avoid it. With the current code the
compiler would be
smart enough to just optimize out the complete branch.
Sure. My point
-B07421; kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On 07.10.2013, at 17:43, Bhushan Bharat-R65777 r65...@freescale.com wrote:
at least when I can avoid it. With the current code the
compiler would
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, October 07, 2013 9:43 PM
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2
- epapr_hypercall() is always defined and returns EV_UNIMPLEMENTED
when
On Mon, 2013-10-07 at 22:23 +0530, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1-v2
- epapr_hypercall
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- CONFIG_KVM_GUEST implies CONFIG_EPAPR_PARAVIRT, so using only
CONFIG_EPAPR_PARAVIRT
/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On Wed, 2013-10-02 at 19:54 +0200, Alexander Graf wrote:
On 02.10.2013, at 19:49, Scott Wood wrote:
On Wed, 2013-10-02 at 19:46 +0200, Alexander Graf wrote:
On 02.10.2013, at 19:42, Scott Wood wrote:
On Wed, 2013-10-02 at 19:17
/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall()
On Wed, 2013-10-02 at 19:54 +0200, Alexander Graf wrote:
On 02.10.2013, at 19:49, Scott Wood wrote:
On Wed, 2013-10-02 at 19:46 +0200, Alexander Graf wrote:
On 02.10.2013, at 19:42, Scott Wood wrote:
On Wed, 2013-10-02 at 19:17
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, October 03, 2013 12:04 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-...@vger.kernel.org; kvm@vger.kernel.org;
Bhushan
Bharat-R65777
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall() to
epapr_hypercall
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, October 03, 2013 12:04 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; k...@vger.kernel.org;
Bhushan
Bharat-R65777
Subject: Re: [PATCH 1/2] kvm/powerpc: rename kvm_hypercall
On 23.09.2013, at 07:23, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/include/asm/epapr_hcalls.h
[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when CONFIG_EPAPR_PARAVIRT=n? We wouldn't have
epapr_hcalls.S compiled into the code base then and the bl above would
reference
,
unsigned long *r2)
unsigned long out[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when CONFIG_EPAPR_PARAVIRT=n? We wouldn't have
epapr_hcalls.S compiled into the code base
+54,7 @@ static inline long kvm_hypercall0_1(unsigned int nr,
unsigned long *r2)
unsigned long out[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when CONFIG_EPAPR_PARAVIRT=n? We
(unsigned int nr, unsigned long *r2)
@@ -65,7 +54,7 @@ static inline long kvm_hypercall0_1(unsigned int nr,
unsigned long *r2)
unsigned long out[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when
kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
It wouldn't ever get called because kvm_hypercall() ends up always returning
EV_UNIMPLEMENTED when
, no?
No.
Like kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
It wouldn't ever get called because kvm_hypercall() ends up always
.
But you can not select KVM_GUEST and still call these inline functions,
no?
No.
Like kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall
selects EPAPR_PARAVIRT.
But you can not select KVM_GUEST and still call these inline functions,
no?
No.
Like kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which
that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
It wouldn't ever get called because kvm_hypercall() ends up always
returning EV_UNIMPLEMENTED when #ifndef CONFIG_KVM_GUEST.
OK, so the objection is to removing that stub
On 23.09.2013, at 07:23, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/include/asm/epapr_hcalls.h
[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when CONFIG_EPAPR_PARAVIRT=n? We wouldn't have
epapr_hcalls.S compiled into the code base then and the bl above would
reference
,
unsigned long *r2)
unsigned long out[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when CONFIG_EPAPR_PARAVIRT=n? We wouldn't have
epapr_hcalls.S compiled into the code base
+54,7 @@ static inline long kvm_hypercall0_1(unsigned int nr,
unsigned long *r2)
unsigned long out[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when CONFIG_EPAPR_PARAVIRT=n? We
(unsigned int nr, unsigned long *r2)
@@ -65,7 +54,7 @@ static inline long kvm_hypercall0_1(unsigned int nr,
unsigned long *r2)
unsigned long out[8];
unsigned long r;
- r = kvm_hypercall(in, out, KVM_HCALL_TOKEN(nr));
+ r = epapr_hypercall(in, out, KVM_HCALL_TOKEN(nr));
Won't this break when
kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
It wouldn't ever get called because kvm_hypercall() ends up always returning
EV_UNIMPLEMENTED when
, no?
No.
Like kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
It wouldn't ever get called because kvm_hypercall() ends up always
.
But you can not select KVM_GUEST and still call these inline functions,
no?
No.
Like kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall
selects EPAPR_PARAVIRT.
But you can not select KVM_GUEST and still call these inline functions,
no?
No.
Like kvm_arch_para_features().
Where does that get called without KVM_GUEST?
How would that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which
that work currently, with the call to kvm_hypercall() in
arch/powerpc/kernel/kvm.c (which calls epapr_hypercall, BTW)?
It wouldn't ever get called because kvm_hypercall() ends up always
returning EV_UNIMPLEMENTED when #ifndef CONFIG_KVM_GUEST.
OK, so the objection is to removing that stub
On Mon, 2013-09-23 at 10:53 +0530, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
[snip]
+ out[0] = r4;
+ out[1] = r5;
+ out[2] = r6;
+ out[3] = r7;
+ out[4
On Mon, 2013-09-23 at 17:45 -0500, Scott Wood wrote:
On Mon, 2013-09-23 at 10:53 +0530, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
[snip]
+ out[0] = r4;
+ out[1] = r5
On Mon, 2013-09-23 at 10:53 +0530, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
[snip]
+ out[0] = r4;
+ out[1] = r5;
+ out[2] = r6;
+ out[3] = r7;
+ out[4
On Mon, 2013-09-23 at 17:45 -0500, Scott Wood wrote:
On Mon, 2013-09-23 at 10:53 +0530, Bharat Bhushan wrote:
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
[snip]
+ out[0] = r4;
+ out[1] = r5
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/include/asm/epapr_hcalls.h | 36 +++
arch/powerpc
kvm_hypercall() have nothing KVM specific, so renamed to epapr_hypercall().
Also this in moved to arch/powerpc/include/asm/epapr_hcalls.h
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/include/asm/epapr_hcalls.h | 36 +++
arch/powerpc
Hi Avi - Yes the control is not coming to neither kvm_handle_exit nor
handle_vmcall after the hypercall is made from the guest.
If I am not wrong, the KVM_HYPERCALL instruction is expected to work, isn't
it?
Thx,
Venkat
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com
Kumar, Venkat wrote:
Hi Avi - Yes the control is not coming to neither kvm_handle_exit nor
handle_vmcall after the hypercall is made from the guest.
If I am not wrong, the KVM_HYPERCALL instruction is expected to work, isn't
it?
Yes, it should. Are you sure the guest is executing
Kumar, Venkat wrote:
Hi Avi - Yes the control is not coming to neither kvm_handle_exit nor
handle_vmcall after the hypercall is made from the guest.
If I am not wrong, the KVM_HYPERCALL instruction is expected to work, isn't
it?
Hi Venkat,
I have used this method of IO many times
Ok. With KVM-85 it works. I was using KVM-84 earlier.
Thx,
Venkat
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, May 18, 2009 5:03 PM
To: Kumar, Venkat
Cc: kvm@vger.kernel.org
Subject: Re: KVM_HYPERCALL
Kumar, Venkat wrote:
Hi Avi - Yes the control
Kumar, Venkat wrote:
I am making a hypercall kvm_hypercall0 with number 0 from a Linux guest. But I don't see the
control coming to handle_vmcall or even kvm_handle_exit. What could be the reason?
No idea. kvm_handle_exit() is called very frequently, even without
hypercalls. Are you
I am making a hypercall kvm_hypercall0 with number 0 from a Linux guest. But
I don't see the control coming to handle_vmcall or even kvm_handle_exit.
What could be the reason?
Thx,
Venkat
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
57 matches
Mail list logo
