On 02/21/2013 02:22:09 AM, Gleb Natapov wrote:
On Wed, Feb 20, 2013 at 08:05:12PM -0600, Scott Wood wrote:
On 02/20/2013 07:09:49 AM, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 03:16:37PM -0600, Scott Wood wrote:
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05
On 02/21/2013 05:03:32 PM, Marcelo Tosatti wrote:
On Wed, Feb 20, 2013 at 07:28:52PM -0600, Scott Wood wrote:
On 02/20/2013 06:14:37 PM, Marcelo Tosatti wrote:
On Wed, Feb 20, 2013 at 05:53:20PM -0600, Scott Wood wrote:
It is then not necessary to set device attributes on a live
guest
On 02/21/2013 02:22:09 AM, Gleb Natapov wrote:
On Wed, Feb 20, 2013 at 08:05:12PM -0600, Scott Wood wrote:
On 02/20/2013 07:09:49 AM, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 03:16:37PM -0600, Scott Wood wrote:
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05
On 02/20/2013 03:17:27 PM, Marcelo Tosatti wrote:
On Mon, Feb 18, 2013 at 05:01:40PM -0600, Scott Wood wrote:
On 02/18/2013 06:21:59 AM, Gleb Natapov wrote:
Copying Christoffer since ARM has in kernel irq chip too.
On Wed, Feb 13, 2013 at 11:49:15PM -0600, Scott Wood wrote:
Currently
On 02/20/2013 03:28:24 PM, Marcelo Tosatti wrote:
On Wed, Feb 20, 2013 at 03:09:49PM +0200, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 03:16:37PM -0600, Scott Wood wrote:
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05:01:40PM -0600, Scott Wood wrote
On 02/20/2013 01:58:54 PM, Marcelo Tosatti wrote:
This is probably a stupid question, but why the
KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate for
your purposes?
x86 sets up a default GSI-IRQCHIP PIN mapping on creation (during
KVM_SET_IRQCHIP), but it can be modified with
On 02/20/2013 06:01:00 PM, Marcelo Tosatti wrote:
The main problem, to me, is that the interface allows flexibility but
the details of using such flexibility are not worked out.
That is, lack of definitions such as when setting attributes is
allowed.
That is defined by the individual
On 02/20/2013 06:14:37 PM, Marcelo Tosatti wrote:
On Wed, Feb 20, 2013 at 05:53:20PM -0600, Scott Wood wrote:
It is then not necessary to set device attributes on a live guest
and
deal with the complications associated with that.
Which complications?
-Scott
Semantics of individual
On 02/20/2013 07:09:55 PM, Marcelo Tosatti wrote:
On Wed, Feb 20, 2013 at 06:20:51PM -0600, Scott Wood wrote:
On 02/20/2013 01:58:54 PM, Marcelo Tosatti wrote:
This is probably a stupid question, but why the
KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate
for
your
On 02/20/2013 07:09:49 AM, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 03:16:37PM -0600, Scott Wood wrote:
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05:01:40PM -0600, Scott Wood wrote:
The ability to set/get attributes is needed. Sorry, but get or
set
one
On 02/20/2013 01:58:54 PM, Marcelo Tosatti wrote:
This is probably a stupid question, but why the
KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate for
your purposes?
x86 sets up a default GSI-IRQCHIP PIN mapping on creation (during
KVM_SET_IRQCHIP), but it can be modified with
On 02/20/2013 06:01:00 PM, Marcelo Tosatti wrote:
The main problem, to me, is that the interface allows flexibility but
the details of using such flexibility are not worked out.
That is, lack of definitions such as when setting attributes is
allowed.
That is defined by the individual
On 02/20/2013 07:09:55 PM, Marcelo Tosatti wrote:
On Wed, Feb 20, 2013 at 06:20:51PM -0600, Scott Wood wrote:
On 02/20/2013 01:58:54 PM, Marcelo Tosatti wrote:
This is probably a stupid question, but why the
KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate
for
your
On 02/20/2013 07:09:49 AM, Gleb Natapov wrote:
On Tue, Feb 19, 2013 at 03:16:37PM -0600, Scott Wood wrote:
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05:01:40PM -0600, Scott Wood wrote:
The ability to set/get attributes is needed. Sorry, but get or
set
one
On 02/18/2013 11:50:44 PM, Christoffer Dall wrote:
On Mon, Feb 18, 2013 at 4:53 PM, Scott Wood scottw...@freescale.com
wrote:
On 02/18/2013 06:44:20 PM, Christoffer Dall wrote:
On Wed, Feb 13, 2013 at 9:49 PM, Scott Wood
scottw...@freescale.com
+#define KVM_CREATE_DEVICE_IOWR
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05:01:40PM -0600, Scott Wood wrote:
The ability to set/get attributes is needed. Sorry, but get or set
one blob of data, up to 512 bytes, for the entire irqchip is just
not good enough -- assuming you don't want us
On 02/19/2013 06:41:11 PM, Paul Mackerras wrote:
On Mon, Feb 18, 2013 at 04:43:27PM -0600, Scott Wood wrote:
On 02/15/2013 10:51:16 PM, Paul Mackerras wrote:
The KVM_CREATE_IRQCHIP_ARGS ioctl says that you want emulation of a
specific interrupt controller architecture connected to the vcpus
On 02/19/2013 06:24:18 AM, Gleb Natapov wrote:
On Mon, Feb 18, 2013 at 05:01:40PM -0600, Scott Wood wrote:
The ability to set/get attributes is needed. Sorry, but get or set
one blob of data, up to 512 bytes, for the entire irqchip is just
not good enough -- assuming you don't want us
On 02/15/2013 10:51:16 PM, Paul Mackerras wrote:
On Fri, Feb 15, 2013 at 09:57:06PM -0600, Scott Wood wrote:
On 02/15/2013 08:56:14 PM, Paul Mackerras wrote:
I have no particular objection to the device control API per se,
but
I have two objections to using it as the primary interface
On 02/18/2013 06:21:59 AM, Gleb Natapov wrote:
Copying Christoffer since ARM has in kernel irq chip too.
On Wed, Feb 13, 2013 at 11:49:15PM -0600, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given
On 02/18/2013 06:04:51 AM, Gleb Natapov wrote:
Can you tell us why mpic should be in kernel? Is it used often by
modern
guests or may be they prefer MSI for interrupt delivery (hmm may be
MSIs
are delivered through mpic too)?
Yes, MSIs are delivered through the mpic.
Plus, MSIs are only
On 02/18/2013 06:44:20 PM, Christoffer Dall wrote:
On Wed, Feb 13, 2013 at 9:49 PM, Scott Wood scottw...@freescale.com
wrote:
index 0350e0d..dbaf012 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -335,6 +335,25 @@ struct kvm_memslots {
short id_to_index
The existing check handles the case where we've migrated to a different
core than we last ran on, but it doesn't handle the case where we're
still on the same cpu we last ran on, but some other vcpu has run on
this cpu in the meantime.
Signed-off-by: Scott Wood scottw...@freescale.com
On 02/15/2013 10:51:16 PM, Paul Mackerras wrote:
On Fri, Feb 15, 2013 at 09:57:06PM -0600, Scott Wood wrote:
On 02/15/2013 08:56:14 PM, Paul Mackerras wrote:
I have no particular objection to the device control API per se,
but
I have two objections to using it as the primary interface
On 02/18/2013 06:21:59 AM, Gleb Natapov wrote:
Copying Christoffer since ARM has in kernel irq chip too.
On Wed, Feb 13, 2013 at 11:49:15PM -0600, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given
On 02/18/2013 06:04:51 AM, Gleb Natapov wrote:
Can you tell us why mpic should be in kernel? Is it used often by
modern
guests or may be they prefer MSI for interrupt delivery (hmm may be
MSIs
are delivered through mpic too)?
Yes, MSIs are delivered through the mpic.
Plus, MSIs are only
On 02/18/2013 06:44:20 PM, Christoffer Dall wrote:
On Wed, Feb 13, 2013 at 9:49 PM, Scott Wood scottw...@freescale.com
wrote:
index 0350e0d..dbaf012 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -335,6 +335,25 @@ struct kvm_memslots {
short id_to_index
The existing check handles the case where we've migrated to a different
core than we last ran on, but it doesn't handle the case where we're
still on the same cpu we last ran on, but some other vcpu has run on
this cpu in the meantime.
Signed-off-by: Scott Wood scottw...@freescale.com
On 02/14/2013 06:16:18 PM, Alexander Graf wrote:
When we invalidate shadow TLB maps on the host, we don't mark them
as not valid. But we should.
Fix this by removing the E500_TLB_VALID from their flags when
invalidating.
Signed-off-by: Alexander Graf ag...@suse.de
---
On 02/14/2013 06:01:08 PM, Paul Mackerras wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
This adds in-kernel emulation of the XICS (eXternal Interrupt
Controller Specification) interrupt controller specified by PAPR, for
both HV and PR KVM guests.
This adds a new
On 02/15/2013 05:18:31 PM, Paul Mackerras wrote:
On Fri, Feb 15, 2013 at 02:05:41PM -0600, Scott Wood wrote:
On 02/14/2013 06:01:08 PM, Paul Mackerras wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
This adds in-kernel emulation of the XICS (eXternal Interrupt
Controller
On 02/15/2013 08:56:14 PM, Paul Mackerras wrote:
I have no particular objection to the device control API per se, but
I have two objections to using it as the primary interface to the XICS
emulation.
First, I dislike the magical side-effect where creating a device of a
particular type (e.g.
On 02/14/2013 06:16:18 PM, Alexander Graf wrote:
When we invalidate shadow TLB maps on the host, we don't mark them
as not valid. But we should.
Fix this by removing the E500_TLB_VALID from their flags when
invalidating.
Signed-off-by: Alexander Graf ag...@suse.de
---
On 02/14/2013 06:01:08 PM, Paul Mackerras wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
This adds in-kernel emulation of the XICS (eXternal Interrupt
Controller Specification) interrupt controller specified by PAPR, for
both HV and PR KVM guests.
This adds a new
On 02/15/2013 05:18:31 PM, Paul Mackerras wrote:
On Fri, Feb 15, 2013 at 02:05:41PM -0600, Scott Wood wrote:
On 02/14/2013 06:01:08 PM, Paul Mackerras wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
This adds in-kernel emulation of the XICS (eXternal Interrupt
Controller
On 02/15/2013 08:56:14 PM, Paul Mackerras wrote:
I have no particular objection to the device control API per se, but
I have two objections to using it as the primary interface to the XICS
emulation.
First, I dislike the magical side-effect where creating a device of a
particular type (e.g.
Scott Wood (3):
kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
kvm/ppc/e500: eliminate tlb_refs
arch/powerpc/kvm/e500.h | 24 ---
arch/powerpc/kvm/e500_mmu_host.c | 85
Add one to esel values in h2g_tlb1_rmap, so that no mapping can be
distinguished from esel 0. Note that we're not saved by the fact
that host esel 0 is reserved for non-KVM use, because KVM host esel
numbering is not the raw host numbering (see to_htlb1_esel).
Signed-off-by: Scott Wood scottw
It's possible that we're using the same host TLB1 slot to map (a
presumably different portion of) the same guest TLB1 entry. Clear
the bit in the map before setting it, so that if the esels are the same
the bit will remain set.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc
in TLB1.
Since we can have more than one host TLB entry for a given tlbe_ref,
be careful not to clear existing flags that are relevant to other
host TLB entries when preparing a new host TLB entry.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/e500.h | 24
On 02/13/2013 11:37:47 PM, Scott Wood wrote:
Scott Wood (3):
kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
kvm/ppc/e500: eliminate tlb_refs
arch/powerpc/kvm/e500.h | 24 ---
arch/powerpc/kvm
Add one to esel values in h2g_tlb1_rmap, so that no mapping can be
distinguished from esel 0. Note that we're not saved by the fact
that host esel 0 is reserved for non-KVM use, because KVM host esel
numbering is not the raw host numbering (see to_htlb1_esel).
Signed-off-by: Scott Wood scottw
in TLB1.
Since we can have more than one host TLB entry for a given tlbe_ref,
be careful not to clear existing flags that are relevant to other
host TLB entries when preparing a new host TLB entry.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/e500.h | 24
It's possible that we're using the same host TLB1 slot to map (a
presumably different portion of) the same guest TLB1 entry. Clear
the bit in the map before setting it, so that if the esels are the same
the bit will remain set.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc
Remove braces that Linux style doesn't permit, remove space after
'*' that Lindent added, keep error/debug strings contiguous, etc.
Substitute type names, debug prints, etc.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c | 445
enumerated capabilities.
Signed-off-by: Scott Wood scottw...@freescale.com
---
Documentation/virtual/kvm/api.txt| 76 ++
Documentation/virtual/kvm/devices/README |1 +
include/linux/kvm_host.h | 21 +
include/uapi/linux/kvm.h | 25
patch.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c | 1686 +++
1 file changed, 1686 insertions(+)
create mode 100644 arch/powerpc/kvm/mpic.c
diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
new file mode
Remove some parts of the code that are obviously QEMU or Raven specific
before fixing style issues, to reduce the style issues that need to be
fixed.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c | 344 ---
1 file
Hook the MPIC code up to the KVM interfaces, add locking, etc.
TODO: irqfd support
Signed-off-by: Scott Wood scottw...@freescale.com
---
Documentation/virtual/kvm/devices/mpic.txt | 36 ++
arch/powerpc/include/asm/kvm_host.h|9 +-
arch/powerpc/include/asm/kvm_ppc.h |4
on on x86 (why are kvm_arch_vcpu_free and
kvm_arch_vcpu_destroy so different?).
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/powerpc.c | 19 +++
include/linux/kvm_host.h | 19 +++
virt/kvm/kvm_main.c|2 ++
3 files changed, 36
On 02/13/2013 11:37:47 PM, Scott Wood wrote:
Scott Wood (3):
kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid
kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit
kvm/ppc/e500: eliminate tlb_refs
arch/powerpc/kvm/e500.h | 24 ---
arch/powerpc/kvm
On 02/08/2013 04:06:14 AM, Bharat Bhushan wrote:
If userspace wants to change some specific bits of TSR
(timer status register) then it uses GET/SET_SREGS ioctl interface.
So the steps will be:
i) user-space will make get ioctl,
ii) change TSR in userspace
iii) then make set
On 02/08/2013 04:06:14 AM, Bharat Bhushan wrote:
If userspace wants to change some specific bits of TSR
(timer status register) then it uses GET/SET_SREGS ioctl interface.
So the steps will be:
i) user-space will make get ioctl,
ii) change TSR in userspace
iii) then make set
Commit 2765788fcc3dc64920dd2be3d32319b50b1e2813 (KVM: PPC: BookE: Handle
alignment interrupts) broke the build by adding mismatched parentheses.
Signed-off-by: Scott Wood scottw...@freescale.com
---
Against kvm-ppc-queue
arch/powerpc/kvm/booke_interrupts.S |4 ++--
1 file changed, 2
On 02/07/2013 06:20:33 PM, Alexander Graf wrote:
On 07.02.2013, at 23:17, Scott Wood wrote:
Commit 2765788fcc3dc64920dd2be3d32319b50b1e2813 (KVM: PPC: BookE:
Handle
alignment interrupts) broke the build by adding mismatched
parentheses.
Signed-off-by: Scott Wood scottw
On 02/07/2013 06:20:33 PM, Alexander Graf wrote:
On 07.02.2013, at 23:17, Scott Wood wrote:
Commit 2765788fcc3dc64920dd2be3d32319b50b1e2813 (KVM: PPC: BookE:
Handle
alignment interrupts) broke the build by adding mismatched
parentheses.
Signed-off-by: Scott Wood scottw
On 02/03/2013 10:48:29 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, February 02, 2013 4:09 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-...@vger.kernel.org;
kvm@vger.kernel.org
Subject: Re: [PATCH 8/8] KVM:PPC:booke: Allow
On 02/03/2013 10:48:29 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, February 02, 2013 4:09 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
k...@vger.kernel.org
Subject: Re: [PATCH 8/8] KVM:PPC:booke: Allow
On 01/31/2013 06:11:32 PM, Alexander Graf wrote:
On 31.01.2013, at 23:40, Scott Wood wrote:
On 01/31/2013 01:20:39 PM, Alexander Graf wrote:
On 31.01.2013, at 20:05, Alexander Graf wrote:
On 31.01.2013, at 19:54, Scott Wood wrote:
On 01/31/2013 12:52:41 PM, Alexander Graf wrote
On 01/31/2013 06:11:32 PM, Alexander Graf wrote:
On 31.01.2013, at 23:40, Scott Wood wrote:
On 01/31/2013 01:20:39 PM, Alexander Graf wrote:
On 31.01.2013, at 20:05, Alexander Graf wrote:
On 31.01.2013, at 19:54, Scott Wood wrote:
On 01/31/2013 12:52:41 PM, Alexander Graf wrote
On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, January 31, 2013 4:58 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
On 01/31/2013 06:04:29 AM, Alexander Graf wrote:
On 30.01.2013, at 12:12, Bhushan Bharat-R65777 wrote:
On bookehv this is how I am controlling the MSR_DE in hardware MSR.
And why is this whole thing only executed on HV?
On e500v2 we always enable MSR_DE using vcpu-arch.shadow_msr in
On 01/31/2013 12:21:07 PM, Alexander Graf wrote:
How about something like this? Then both targets at least suck as
much :).
I'm not sure that should be the goal...
Thanks to e500mc's awful hardware design, we don't know who sets the
MSR_DE bit. Once we forced it onto the guest, we have no
On 01/31/2013 12:52:41 PM, Alexander Graf wrote:
On 31.01.2013, at 19:43, Scott Wood wrote:
On 01/31/2013 12:21:07 PM, Alexander Graf wrote:
How about something like this? Then both targets at least suck as
much :).
I'm not sure that should be the goal...
Thanks to e500mc's awful
On 01/31/2013 01:20:39 PM, Alexander Graf wrote:
On 31.01.2013, at 20:05, Alexander Graf wrote:
On 31.01.2013, at 19:54, Scott Wood wrote:
On 01/31/2013 12:52:41 PM, Alexander Graf wrote:
On 31.01.2013, at 19:43, Scott Wood wrote:
On 01/31/2013 12:21:07 PM, Alexander Graf wrote:
How
On 01/31/2013 06:04:29 AM, Alexander Graf wrote:
On 30.01.2013, at 12:12, Bhushan Bharat-R65777 wrote:
On bookehv this is how I am controlling the MSR_DE in hardware MSR.
And why is this whole thing only executed on HV?
On e500v2 we always enable MSR_DE using vcpu-arch.shadow_msr in
On 01/31/2013 12:52:41 PM, Alexander Graf wrote:
On 31.01.2013, at 19:43, Scott Wood wrote:
On 01/31/2013 12:21:07 PM, Alexander Graf wrote:
How about something like this? Then both targets at least suck as
much :).
I'm not sure that should be the goal...
Thanks to e500mc's awful
On 01/31/2013 01:20:39 PM, Alexander Graf wrote:
On 31.01.2013, at 20:05, Alexander Graf wrote:
On 31.01.2013, at 19:54, Scott Wood wrote:
On 01/31/2013 12:52:41 PM, Alexander Graf wrote:
On 31.01.2013, at 19:43, Scott Wood wrote:
On 01/31/2013 12:21:07 PM, Alexander Graf wrote:
How
On 01/22/2013 05:54:43 PM, Stuart Yoder wrote:
+.macro BOOK3E_IDLE_LOOP
+1:
+ PPC_WAIT(0)
b 1b
+.endm
+
+.macro EPAPR_EV_IDLE_LOOP
+idle_loop:
+ LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE))
+
+.global epapr_ev_idle_start
+epapr_ev_idle_start:
+ li r3, -1
On 01/18/2013 08:08:01 AM, Alexander Graf wrote:
On 18.01.2013, at 04:05, Scott Wood wrote:
Invalidation paths that call kvmppc_e500_tlbil_all(), such as
MMUCSR0 and tlbivax, need a call to clear_tlb_refs() in order to get
the valid bits cleared.
Yeah, instead of kvmppc_e500_tlbil_all
On 01/17/2013 04:50:39 PM, Alexander Graf wrote:
@@ -1024,9 +1001,11 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64
eaddr, gpa_t gpaddr,
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
struct tlbe_priv *priv;
- struct kvm_book3e_206_tlb_entry *gtlbe, stlbe;
+
On 01/17/2013 04:50:41 PM, Alexander Graf wrote:
When a host mapping fault happens in a guest TLB1 entry today, we
map the translated guest entry into the host's TLB1.
This isn't particularly clever when the guest is mapped by normal 4k
pages, since these would be a lot better to put into TLB0
On 01/17/2013 06:29:56 PM, Alexander Graf wrote:
On 18.01.2013, at 01:20, Alexander Graf wrote:
On 18.01.2013, at 01:11, Scott Wood wrote:
It also seems like it would be cleaner to just invalidate the old
entry
in tlbwe, and then this function doesn't need to change at all. I
am
On 01/17/2013 06:20:03 PM, Alexander Graf wrote:
On 18.01.2013, at 01:11, Scott Wood wrote:
On 01/17/2013 04:50:39 PM, Alexander Graf wrote:
@@ -1024,9 +1001,11 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcpu,
u64 eaddr, gpa_t gpaddr,
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500
On 01/17/2013 08:34:53 PM, Alexander Graf wrote:
When we invalidate shadow TLB maps on the host, we don't mark them
as not valid. But we should.
Fix this by removing the E500_TLB_VALID from their flags when
invalidating.
Signed-off-by: Alexander Graf ag...@suse.de
---
On 01/17/2013 04:50:39 PM, Alexander Graf wrote:
@@ -1024,9 +1001,11 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64
eaddr, gpa_t gpaddr,
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
struct tlbe_priv *priv;
- struct kvm_book3e_206_tlb_entry *gtlbe, stlbe;
+
On 01/17/2013 06:29:56 PM, Alexander Graf wrote:
On 18.01.2013, at 01:20, Alexander Graf wrote:
On 18.01.2013, at 01:11, Scott Wood wrote:
It also seems like it would be cleaner to just invalidate the old
entry
in tlbwe, and then this function doesn't need to change at all. I
am
On 01/17/2013 06:20:03 PM, Alexander Graf wrote:
On 18.01.2013, at 01:11, Scott Wood wrote:
On 01/17/2013 04:50:39 PM, Alexander Graf wrote:
@@ -1024,9 +1001,11 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcpu,
u64 eaddr, gpa_t gpaddr,
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500
On 01/17/2013 08:34:53 PM, Alexander Graf wrote:
When we invalidate shadow TLB maps on the host, we don't mark them
as not valid. But we should.
Fix this by removing the E500_TLB_VALID from their flags when
invalidating.
Signed-off-by: Alexander Graf ag...@suse.de
---
On 01/16/2013 11:21:24 AM, Stuart Yoder wrote:
From: Stuart Yoder stuart.yo...@freescale.com
loop was derived from book3e_idle()
Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
---
arch/powerpc/kernel/epapr_hcalls.S | 63
1 file changed, 63
On 01/11/2013 09:42:55 AM, Alexander Graf wrote:
On 11.01.2013, at 02:10, Scott Wood wrote:
struct kvm_device_attr {
__u32 device;
This needs some semantic specification. Is device a constant value?
Is it the return value of CREATE_IRQCHIP?
As proposed, it's up to the architecture
On 01/10/2013 05:42:16 AM, Alexander Graf wrote:
Other instantiation attributes we don't know that early on should be
settable between the time frame of vm creation and first execution.
An example for this are device addresses. Check out the threads KVM:
ARM: Rename KVM_SET_DEVICE_ADDRESS
On 01/10/2013 04:28:01 PM, Marcelo Tosatti wrote:
On Wed, Jan 09, 2013 at 10:37:20PM +0100, Alexander Graf wrote:
We can start to introduce (and fix ARM) with a generic ioctl
in the MPIC patches then.
The ioctl is already generic, except for its name.
It's making a few wrong
On 01/10/2013 06:35:02 PM, Marcelo Tosatti wrote:
On Thu, Jan 10, 2013 at 04:40:12PM -0600, Scott Wood wrote:
On 01/10/2013 04:28:01 PM, Marcelo Tosatti wrote:
Or just have KVM_SET_PPC_DEVICE_ADDRESS. Is there a downside to
that?
Besides the above, and my original complaint
On 01/09/2013 10:48:47 AM, Alexander Graf wrote:
On 09.01.2013, at 17:26, Christoffer Dall wrote:
Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
to make it obvious that this is ARM specific in lack of a better
generic
interface.
Once we agree on a better interface the
On 01/09/2013 02:12:16 PM, Alexander Graf wrote:
On 09.01.2013, at 20:50, Scott Wood wrote:
On 01/09/2013 10:48:47 AM, Alexander Graf wrote:
On 09.01.2013, at 17:26, Christoffer Dall wrote:
Renames the KVM_SET_DEVICE_ADDRESS to KVM_ARM_SET_DEVICE_ADDR
to make it obvious that this is ARM
On 01/09/2013 03:37:20 PM, Alexander Graf wrote:
Am 09.01.2013 um 22:15 schrieb Scott Wood scottw...@freescale.com:
I get that there's a tradeoff between getting something in now,
versus waiting until the API is more refined. Tagging it with a
particular ISA seems like an odd way
On 01/08/2013 12:41:30 PM, Christoffer Dall wrote:
On ARM (and possibly other architectures) some bits are specific to
the
model being emulated for the guest and user space needs a way to tell
the kernel about those bits. An example is mmio device base
addresses,
where KVM must know the
On 01/08/2013 05:17:05 PM, Christoffer Dall wrote:
On Tue, Jan 8, 2013 at 5:36 PM, Scott Wood scottw...@freescale.com
wrote:
On 01/08/2013 12:41:30 PM, Christoffer Dall wrote:
+struct kvm_device_address {
+ __u64 id;
+ __u64 addr;
+};
What about this is really specific
On 01/08/2013 05:49:40 PM, Christoffer Dall wrote:
On Tue, Jan 8, 2013 at 6:29 PM, Scott Wood scottw...@freescale.com
wrote:
On 01/08/2013 05:17:05 PM, Christoffer Dall wrote:
This *could* look something like this:
struct kvm_device_param {
u64 dev_id;
u64 param_id;
u64
On 01/04/2013 05:41:42 PM, Alexander Graf wrote:
@@ -408,6 +411,11 @@ static int kvmppc_booke_irqprio_deliver(struct
kvm_vcpu *vcpu,
set_guest_esr(vcpu, vcpu-arch.queued_esr);
if (update_dear == true)
set_guest_dear(vcpu,
On 01/04/2013 05:41:42 PM, Alexander Graf wrote:
@@ -408,6 +411,11 @@ static int kvmppc_booke_irqprio_deliver(struct
kvm_vcpu *vcpu,
set_guest_esr(vcpu, vcpu-arch.queued_esr);
if (update_dear == true)
set_guest_dear(vcpu,
On 01/04/2013 11:36:37 AM, Alexander Graf wrote:
When injecting an interrupt into guest context, we usually don't need
to check for requests anymore. At least not until today.
With the introduction of EPR, we will have to create a request when
the
guest has successfully accepted an external
On 01/04/2013 11:36:38 AM, Alexander Graf wrote:
The EPR register is potentially valid for PR KVM as well, so we need
to emulate accesses to it. It's only defined for reading, so only
handle the mfspr case.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/booke_emulate.c |3
On 01/04/2013 11:36:40 AM, Alexander Graf wrote:
We need to be able to read and write the contents of the EPR register
from user space.
This patch implements that logic through the ONE_REG API and declares
its (never implemented) SREGS counterpart as deprecated.
QEMU already uses SREGS to
On 01/04/2013 11:36:39 AM, Alexander Graf wrote:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 4ae83f9..363301f 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -306,7 +306,7 @@ static int kvmppc_booke_irqprio_deliver(struct
kvm_vcpu *vcpu,
{
On 01/04/2013 04:55:34 PM, Alexander Graf wrote:
On 04.01.2013, at 21:08, Scott Wood wrote:
On 01/04/2013 11:36:40 AM, Alexander Graf wrote:
We need to be able to read and write the contents of the EPR
register
from user space.
This patch implements that logic through the ONE_REG API
On 01/04/2013 11:36:38 AM, Alexander Graf wrote:
The EPR register is potentially valid for PR KVM as well, so we need
to emulate accesses to it. It's only defined for reading, so only
handle the mfspr case.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/booke_emulate.c |3
On 01/04/2013 04:55:34 PM, Alexander Graf wrote:
On 04.01.2013, at 21:08, Scott Wood wrote:
On 01/04/2013 11:36:40 AM, Alexander Graf wrote:
We need to be able to read and write the contents of the EPR
register
from user space.
This patch implements that logic through the ONE_REG API
On 12/18/2012 06:38:41 AM, Alexander Graf wrote:
When we hit an emulation result that we didn't expect, that is an
error,
but it's nothing that warrants a BUG(), because it can be guest
triggered.
So instead, let's only WARN() the user that this happened.
Signed-off-by: Alexander Graf
701 - 800 of 1350 matches
Mail list logo
