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
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 -0
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 c
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 -- assumin
On 02/18/2013 11:50:44 PM, Christoffer Dall wrote:
On Mon, Feb 18, 2013 at 4:53 PM, Scott Wood
wrote:
> On 02/18/2013 06:44:20 PM, Christoffer Dall wrote:
>>
>> On Wed, Feb 13, 2013 at 9:49 PM, Scott Wood
>> > +#define KVM_CREATE_DEVICE_I
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
---
This seems t
On 02/18/2013 06:44:20 PM, Christoffer Dall wrote:
On Wed, Feb 13, 2013 at 9:49 PM, Scott Wood
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[KV
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 (n
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
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 pr
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. MPIC
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
> >
> >This adds in-kernel emulation of the XICS (eXternal Interrupt
> &
On 02/14/2013 06:01:08 PM, Paul Mackerras wrote:
From: Benjamin Herrenschmidt
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 KVM_CREATE_IRQCHIP_ARGS ioctl, which is l
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
---
arch/powerpc/kvm/e500_tlb.c | 13 +++
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
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
---
arch/powerpc/kvm/e500_
or E500_TLB_VALID 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
---
arch/powerpc/kvm/e500.h | 24 --
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).
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
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/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: Sco
Commit 2765788fcc3dc64920dd2be3d32319b50b1e2813 ("KVM: PPC: BookE: Handle
alignment interrupts") broke the build by adding mismatched parentheses.
Signed-off-by: Scott Wood
---
Against kvm-ppc-queue
arch/powerpc/kvm/booke_interrupts.S |4 ++--
1 file changed, 2 insertions(+), 2
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: A
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:
>> >
>&g
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
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...
>
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 c
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 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
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_
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
---
arch/powerpc/kvm/e500_tlb.c | 13 +++
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
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
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 i
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/16/2013 11:21:24 AM, Stuart Yoder wrote:
From: Stuart Yoder
loop was derived from book3e_idle()
Signed-off-by: Stuart Yoder
---
arch/powerpc/kernel/epapr_hcalls.S | 63
1 file changed, 63 insertions(+)
diff --git a/arch/powerpc/kernel/epapr_hc
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 a
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 co
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 maki
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/09/2013 03:37:20 PM, Alexander Graf wrote:
Am 09.01.2013 um 22:15 schrieb Scott Wood :
> 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 of saying &qu
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
>> &
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 th
On 01/08/2013 05:49:40 PM, Christoffer Dall wrote:
On Tue, Jan 8, 2013 at 6:29 PM, Scott Wood
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;
>>
On 01/08/2013 05:17:05 PM, Christoffer Dall wrote:
On Tue, Jan 8, 2013 at 5:36 PM, Scott Wood
wrote:
> On 01/08/2013 12:41:30 PM, Christoffer Dall wrote:
>> +struct kvm_device_address {
>> + __u64 id;
>> + __u64 addr;
>> +};
>
>
> What about
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 bas
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, vcpu->ar
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 logi
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 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 read
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
---
arch/powerpc/kvm/booke_emulate.c |3 +++
1 files
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 i
On 12/18/2012 05:01:19 PM, Alexander Graf wrote:
On 18.12.2012, at 23:54, Scott Wood wrote:
> 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()
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
---
On 12/01/2012 07:58:25 AM, Alexander Graf wrote:
In BookE, EPCR is defined and valid when either the HV or the 64bit
category are implemented. Reflect this in the field definition.
Today the only KVM target on 64bit is HV enabled, so there is no
change in actual source code, but this keeps the c
On 11/19/2012 06:36:42 AM, Alexander Graf wrote:
On 14.11.2012, at 05:32, Paul Mackerras wrote:
> +/*
> + * Note modification of an HPTE; set the HPTE modified bit
> + * if it wasn't modified before and anyone is interested.
> + */
> +static inline void note_hpte_modification(struct kvm *kvm,
>
On 10/08/2012 04:01:11 PM, Alexander Graf wrote:
On 08.10.2012, at 22:45, Scott Wood wrote:
> On 10/07/2012 08:30:06 AM, Alexander Graf wrote:
>> On 07.10.2012, at 15:26, Avi Kivity wrote:
>> > The downside of this generic approach is that it prepares
suprises down
&
On 10/07/2012 08:58:02 AM, Alexander Graf wrote:
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
b/arch/powerpc/kvm/bookehv_interrupts.S
index 099fe82..4421293 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -23,7 +23,6 @@
#include
#includ
On 10/07/2012 08:30:06 AM, Alexander Graf wrote:
On 07.10.2012, at 15:26, Avi Kivity wrote:
> The downside of this generic approach is that it prepares suprises
down
> the road. The alternative approach, of adding a new KVM_EXIT_RESET,
> avoids this minefield, but requires ABI changes every
On 09/25/2012 02:44:52 AM, Alexander Graf wrote:
On 23.08.2012, at 03:03, Scott Wood wrote:
> Avoid a race as described in the code comment.
>
> Also remove a related smp_wmb() from booke's
kvmppc_prepare_to_enter().
> I can't see any reason for it, and the book3s_pr
On 09/18/2012 07:02:42 PM, Paul Mackerras wrote:
On Tue, Sep 18, 2012 at 04:06:25PM +0200, Alexander Graf wrote:
> Could you please merge the registers that you share with book3s pr
> into shared code?
OK - that's just DAR and DSISR for this patch, isn't it?
And basically all of the FP/VMX/VSX r
On 09/12/2012 04:45 PM, Alexander Graf wrote:
>
>
> On 12.09.2012, at 23:38, Scott Wood wrote:
>
>> On 09/12/2012 01:56 PM, Alexander Graf wrote:
>>>
>>>
>>> On 12.09.2012, at 15:18, Mihai Caraman wrote:
>>>
>>>> The cu
On 09/12/2012 01:56 PM, Alexander Graf wrote:
>
>
> On 12.09.2012, at 15:18, Mihai Caraman wrote:
>
>> The current form of DO_KVM macro restricts its use to one call per input
>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
>> definition.
>> Duplicate calls of DO_KVM ar
se.de; Bhushan
>> Bharat-
>> R65777
>> Subject: Re: [PATCH 6/6] KVM: booke/bookehv: Add debug stub support
>>
>> On 09/05/2012 06:23 PM, Scott Wood wrote:
>>> On 08/21/2012 08:52 AM, Bharat Bhushan wrote:
>>>> This patch adds the debug stub support on
On 09/05/2012 06:23 PM, Scott Wood wrote:
> On 08/21/2012 08:52 AM, Bharat Bhushan wrote:
>> This patch adds the debug stub support on booke/bookehv.
>> Now QEMU debug stub can use hw breakpoint, watchpoint and
>> software breakpoint to debug guest.
>>
>&
On 08/21/2012 08:51 AM, Bharat Bhushan wrote:
> Signed-off-by: Bharat Bhushan
> ---
> arch/powerpc/include/asm/reg_booke.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index e07e6af.
On 08/21/2012 08:52 AM, Bharat Bhushan wrote:
> This patch adds the debug stub support on booke/bookehv.
> Now QEMU debug stub can use hw breakpoint, watchpoint and
> software breakpoint to debug guest.
>
> Signed-off-by: Bharat Bhushan
> ---
> arch/powerpc/include/asm/kvm.h| 29 ++
This was found by kmemleak.
Signed-off-by: Scott Wood
---
arch/powerpc/kvm/e500_tlb.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch/powerpc/kvm/e500_tlb.c
index a27d134..641f978 100644
--- a/arch/powerpc/kvm/e500_tlb.c
+++ b/arch/powerpc/kvm
We were only allocating half the bytes we need, which was made more
obvious by a recent fix to the memset in clear_tlb1_bitmap().
Signed-off-by: Scott Wood
---
arch/powerpc/kvm/e500_tlb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/e500_tlb.c b/arch
Avoid a race as described in the code comment.
Also remove a related smp_wmb() from booke's kvmppc_prepare_to_enter().
I can't see any reason for it, and the book3s_pr version doesn't have it.
Signed-off-by: Scott Wood
---
arch/powerpc/kvm/booke.c |1 -
arch/powerpc/kvm/p
On 08/15/2012 04:29 AM, Alexander Graf wrote:
>
> On 15.08.2012, at 03:17, Scott Wood wrote:
>
>> On 08/14/2012 07:26 PM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 02:17, Scott Wood wrote:
>>>
>>>> On 08/14/2012 06:04 PM, Alexander
On 08/16/2012 10:12 AM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Tuesday, July 31, 2012 3:31 AM
>> To: Bhushan Bharat-R65777
>> Cc: Wood Scott-B07421; kvm-...@vger.kernel.org; kvm@vger.kernel.org;
>> ag...@suse.de
>> Subject: Re: [PATCH 2/
On 08/16/2012 03:48 AM, Bhushan Bharat-R65777 wrote:
> diff --git a/arch/powerpc/include/asm/kvm.h
> b/arch/powerpc/include/asm/kvm.h index 3c14202..da71c84 100644
> --- a/arch/powerpc/include/asm/kvm.h
> +++ b/arch/powerpc/include/asm/kvm.h
> @@ -25,6 +25,7 @@
> /* Select
On 08/15/2012 02:29 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 21:05, Scott Wood wrote:
>
>> On 08/15/2012 01:58 PM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 20:56, Scott Wood wrote:
>>>
>>>> On 08/15/2012 01:51 PM, Alexander
On 08/15/2012 01:58 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 20:56, Scott Wood wrote:
>
>> On 08/15/2012 01:51 PM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 20:33, Scott Wood wrote:
>>>
>>>> On 08/15/2012 01:29 PM, Alexander Graf
On 08/15/2012 01:51 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 20:33, Scott Wood wrote:
>
>> On 08/15/2012 01:29 PM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 20:27, Alexander Graf wrote:
>>>
>>>>
>>>> On 15.08.2
On 08/15/2012 01:29 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 20:27, Alexander Graf wrote:
>
>>
>> On 15.08.2012, at 20:16, Scott Wood wrote:
>>
>>> On 08/15/2012 01:01 PM, Alexander Graf wrote:
>>>>
>>>> On 15.08.2012, a
On 08/15/2012 01:01 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 19:47, Scott Wood wrote:
>
>> On 08/15/2012 12:27 PM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 19:26, Scott Wood wrote:
>>>
>>>> On 08/15/2012 04:52 AM, Alexander
On 08/15/2012 12:27 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 19:26, Scott Wood wrote:
>
>> On 08/15/2012 04:52 AM, Alexander Graf wrote:
>>>
>>> On 15.08.2012, at 03:23, Scott Wood wrote:
>>>
>>>> On 08/14/2012 06:04 PM, Alexander G
On 08/15/2012 04:52 AM, Alexander Graf wrote:
>
> On 15.08.2012, at 03:23, Scott Wood wrote:
>
>> On 08/14/2012 06:04 PM, Alexander Graf wrote:
>>> When we map a page that wasn't icache cleared before, do so when first
>>> mapping it in KVM using the same
On 08/14/2012 06:04 PM, Alexander Graf wrote:
> + /* Going into guest context! Yay! */
> + vcpu->mode = IN_GUEST_MODE;
> + smp_wmb();
> +
> break;
> }
What is the wmb protecting against here?
-Scott
--
To unsubscribe from this list: send t
On 08/14/2012 06:04 PM, Alexander Graf wrote:
> When we map a page that wasn't icache cleared before, do so when first
> mapping it in KVM using the same information bits as the Linux mapping
> logic. That way we are 100% sure that any page we map does not have stale
> entries in the icache.
We're
On 08/14/2012 06:04 PM, Alexander Graf wrote:
> The e500 target has lived without mmu notifiers ever since it got
> introduced, but fails for the user space check on them with hugetlbfs.
>
> So in order to get that one working, implement mmu notifiers in a
> reasonably dumb fashion and be happy. O
On 08/14/2012 07:26 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 02:17, Scott Wood wrote:
>
>> On 08/14/2012 06:04 PM, Alexander Graf wrote:
>>> Generic KVM code might want to know whether we are inside guest context
>>> or outside. It also wants to be abl
On 08/14/2012 07:13 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 02:10, Scott Wood wrote:
>
>> On 08/14/2012 06:04 PM, Alexander Graf wrote:
>>> We need a central place to check for pending requests in. Add one that
>>> only does the timer check w
On 08/14/2012 06:04 PM, Alexander Graf wrote:
> Generic KVM code might want to know whether we are inside guest context
> or outside. It also wants to be able to push us out of guest context.
>
> Add support to the BookE code for the generic vcpu->mode field that describes
> the above states.
>
>
On 08/14/2012 06:04 PM, Alexander Graf wrote:
> We need a central place to check for pending requests in. Add one that
> only does the timer check we already do in a different place.
>
> Later, this central function can be extended by more checks.
>
> Signed-off-by: Alexander Graf
> ---
> arch/
On 08/14/2012 06:47 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 01:44, Scott Wood wrote:
>
>> On 08/14/2012 06:04 PM, Alexander Graf wrote:
>>> From: Bharat Bhushan
>>>
>>> IAC/DAC are defined as 32 bit while they are 64 bit wide. So ONE_
On 08/14/2012 06:04 PM, Alexander Graf wrote:
> From: Bharat Bhushan
>
> IAC/DAC are defined as 32 bit while they are 64 bit wide. So ONE_REG
> interface is added to set/get them.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Alexander Graf
> ---
> arch/powerpc/include/asm/kvm.h |
On 08/11/2012 08:07 AM, Tabi Timur-B04825 wrote:
> On Sat, Aug 11, 2012 at 2:01 AM, Geert Uytterhoeven
> wrote:
>> On Sat, Aug 11, 2012 at 12:21 AM, Scott Wood wrote:
>>> +EXPORT_SYMBOL(epapr_hypercall_start);
>>
>> EXPORT_SYMBOL_GPL?
>
> We prefer EXPORT
odule.
Reported-by: Geert Uytterhoeven
Signed-off-by: Scott Wood
---
Sending to Alex even though this isn't KVM-specific since the commit it
fixes is still only in his tree (and linux-next).
arch/powerpc/kernel/ppc_ksyms.c |5 +
1 file changed, 5 insertions(+)
diff --git a/ar
On 08/07/2012 05:57 AM, Alexander Graf wrote:
> When we map a page that wasn't icache cleared before, do so when first
> mapping it in KVM using the same information bits as the Linux mapping
> logic. That way we are 100% sure that any page we map does not have stale
> entries in the icache.
>
> W
On 08/07/2012 05:47 AM, Alexander Graf wrote:
>> diff --git a/arch/powerpc/kvm/booke_interrupts.S
>> b/arch/powerpc/kvm/booke_interrupts.S
>> index 3539805..890673c 100644
>> --- a/arch/powerpc/kvm/booke_interrupts.S
>> +++ b/arch/powerpc/kvm/booke_interrupts.S
>> @@ -73,6 +73,51 @@ _GLOBAL(kvmppc
On 08/05/2012 04:00 AM, Avi Kivity wrote:
> On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
>> On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
>>
>>> See kvm_arch_process_async_events() call to qemu_system_reset_request()
>>> in target-i386/kvm.c.
>>>
>>> The whole thing is fragile,
On 08/02/2012 10:56 AM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Wood Scott-B07421
>> Sent: Wednesday, August 01, 2012 11:31 PM
>> To: Bhushan Bharat-R65777
>> Cc: Alexander Graf; qemu-...@nongnu.org List; kvm-...@vger.kernel.org; qemu-
>> devel qemu-devel; KVM list
On 08/01/2012 12:27 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, August 01, 2012 7:57 AM
>> To: Bhushan Bharat-R65777
>> Cc: qemu-...@nongnu.org List; kvm-...@vger.kernel.org; Bhushan Bharat-R65777;
>> qemu-d
On 07/31/2012 06:59 PM, Alexander Graf wrote:
> Well, user space always comes in via the ioctl path, which in turn
> does vcpu_load(vcpu), thus should always be running as the vcpu
> context itself.
Right, it's the timers you're racing with.
> It boils down to the original thing I was saying back
for watchdog emulation and emulates
>> h/w watchdog state machine. On watchdog timer expiry, it exit to QEMU
>> if TCR.WRC is non ZERO. QEMU can reset/shutdown etc depending upon how
>> it is configured.
>>
>> Signed-off-by: Liu Yu
>> Signed-off-by: Scott Wood
On 07/30/2012 06:11 AM, Bharat Bhushan wrote:
> +1: /* debug interrupt happened in guest */
> + mfspr r4, \scratch
> + mtcrr3
> + mr r3, r4
> + mfspr r4, SPRN_SPRG_THREAD
> + lwz r4, THREAD_KVM_VCPU(r4)
> + stw r3, VCPU_GPR(r4)(r4)
> + stw r5,
401 - 500 of 731 matches
Mail list logo
