On 06/30/2010 04:18 PM, Alexander Graf wrote:
Book3s suffered from my really bad shadow MMU implementation so far. So
I finally got around to implement a combined hash and list mechanism that
allows for much faster lookup of mapped pages.
To show that it really is faster, I tried to run simple p
Hi Scott,
> How do I find the address, reg, and range for nodes like localbus,
> soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
> relate to IMMR? So my localbus and soc should be as follows?
>
> local...@fa200100 {
> compatible = "fsl,mpc885-localbus", "fsl
On 01.07.2010, at 09:29, Avi Kivity wrote:
> On 06/30/2010 04:18 PM, Alexander Graf wrote:
>> Book3s suffered from my really bad shadow MMU implementation so far. So
>> I finally got around to implement a combined hash and list mechanism that
>> allows for much faster lookup of mapped pages.
>>
On 07/01/2010 11:18 AM, Alexander Graf wrote:
How does dirty bitmap flushing work on x86 atm? I loop through all mapped pages
and flush the ones that match the range of the region I need to flush. But
wouldn't it be a lot more efficient to have an hlist in the memslot and loop
through that wh
Fushen,
On Wednesday 30 June 2010 22:16:52 fushen chen wrote:
> The driver is based on Synopsys driver 2.60a.
OK.
> We started to prepare open source submission based on our internal
> version. We sync this version to linux-2.6-denx repository from time to
> time. I'll sync the driver to the la
Avi Kivity wrote:
> On 07/01/2010 11:18 AM, Alexander Graf wrote:
>>
>> How does dirty bitmap flushing work on x86 atm? I loop through all
>> mapped pages and flush the ones that match the range of the region I
>> need to flush. But wouldn't it be a lot more efficient to have an
>> hlist in the mem
On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
hypervisor extensions.
While that is all great to show that virtualization is possible, there are
quite some cases where the emulation overhead of privileged instructions is
killing performance.
This patchset tackles exac
For transparent variable sharing between the hypervisor and guest, I introduce
a shared page. This shared page will contain all the registers the guest can
read and write safely without exiting guest context.
This patch only implements the stubs required for the basic structure of the
shared page.
When in kernel mode there are 4 additional registers available that are
simple data storage. Instead of exiting to the hypervisor to read and
write those, we can just share them with the guest using the page.
This patch converts all users of the current field to the shared page.
Signed-off-by: Al
The DSISR register contains information about a data page fault. It is fully
read/write from inside the guest context and we don't need to worry about
interacting based on writes of this register.
This patch converts all users of the current field to the shared page.
Signed-off-by: Alexander Graf
To communicate with KVM directly we need to plumb some sort of interface
between the guest and KVM. Usually those interfaces use hypercalls.
This hypercall implementation is described in the last patch of the series
in a special documentation file. Please read that for further information.
This p
We will be introducing a method to project the shared page in guest context.
As soon as we're talking about this coupling, the shared page is colled magic
page.
This patch introduces simple defines, so the follow-up patches are easier to
read.
Signed-off-by: Alexander Graf
---
arch/powerpc/incl
The DAR register contains the address a data page fault occured at. This
register behaves pretty much like a simple data storage register that gets
written to on data faults. There is no hypervisor interaction required on
read or write.
This patch converts all users of the current field to the sha
Now that we have the shared page in place and the MMU code knows about
the magic page, we can expose that capability to the guest!
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_para.h |2 ++
arch/powerpc/kvm/powerpc.c | 11 +++
2 files changed, 13 insertio
Currently x86 is the only architecture that uses kvm_guest_init(). With
PowerPC we're getting a second user, but the signature is different there
and we don't need to export it, as it uses the normal kernel init framework.
So let's move the x86 specific definition of that function over to the x86
We will soon start and replace instructions from the text section with
other, paravirtualized versions. To ease the readability of those patches
I split out the generic looping and magic page mapping code out.
This patch still only contains stubs. But at least it loops through the
text section :).
With our current MMU scheme we don't need to know about the tlbsync instruction.
So we can just nop it out.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- use kvm_patch_ins
---
arch/powerpc/kernel/kvm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch
While running in hooked code we need to store register contents out because
we must not clobber any registers.
So let's add some fields to the shared page we can just happily write to.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_para.h |3 +++
1 files changed, 3 insertion
The SRR0 and SRR1 registers contain cached values of the PC and MSR
respectively. They get written to by the hypervisor when an interrupt
occurs or directly by the kernel. They are also used to tell the rfi(d)
instruction where to jump to.
Because it only gets touched on defined events that, it's
On PowerPC it's very normal to not support all of the physical RAM in real mode.
To check if we're matching on the shared page or not, we need to know the limits
so we can restrain ourselves to that range.
So let's make it a define instead of open-coding it. And while at it, let's also
increase it
When running in hooked code we need a way to disable interrupts without
clobbering any interrupts or exiting out to the hypervisor.
To achieve this, we have an additional critical field in the shared page. If
that field is equal to the r1 register of the guest, it tells the hypervisor
that we're i
When the guest turns on interrupts again, it needs to know if we have an
interrupt pending for it. Because if so, it should rather get out of guest
context and get the interrupt.
So we introduce a new field in the shared page that we use to tell the guest
that there's a pending interrupt lying aro
We need to override EA as well as PA lookups for the magic page. When the guest
tells us to project it, the magic page overrides any guest mappings.
In order to reflect that, we need to hook into all the MMU layers of KVM to
force map the magic page if necessary.
Signed-off-by: Alexander Graf
v
When we hook an instruction we need to make sure we don't clobber any of
the registers at that point. So we write them out to scratch space in the
magic page. To make sure we don't fall into a race with another piece of
hooked code, we need to disable interrupts.
To make the later patches and code
We have all the hypervisor pieces in place now, but the guest parts are still
missing.
This patch implements basic awareness of KVM when running Linux as guest. It
doesn't do anything with it yet though.
Signed-off-by: Alexander Graf
---
arch/powerpc/kernel/Makefile |2 ++
arch/powerpc
One of the most obvious registers to share with the guest directly is the
MSR. The MSR contains the "interrupts enabled" flag which the guest has to
toggle in critical sections.
So in order to bring the overhead of interrupt en- and disabling down, let's
put msr into the shared page. Keep in mind
On BookE the preferred way to write the EE bit is the wrteei instruction. It
already encodes the EE bit in the instruction.
So in order to get BookE some speedups as well, let's also PV'nize thati
instruction.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- use kvm_patch_ins_b
---
arch/power
We will need to patch several instruction streams over to a different
code path, so we need a way to patch a single instruction with a branch
somewhere else.
This patch adds a helper to facilitate this patching.
Signed-off-by: Alexander Graf
---
arch/powerpc/kernel/kvm.c |5 +
1 files c
We will soon require more sophisticated methods to replace single instructions
with multiple instructions. We do that by branching to a memory region where we
write replacement code for the instruction to.
This region needs to be within 32 MB of the patched instruction though, because
that's the f
We just introduced a new PV interface that screams for documentation. So here
it is - a shiny new and awesome text file describing the internal works of
the PPC KVM paravirtual interface.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- clarify guest implementation
- clarify that privileged i
The PowerPC ISA has a special instruction for mtmsr that only changes the EE
and RI bits, namely the L=1 form.
Since that one is reasonably often occuring and simple to implement, let's
go with this first. Writing EE=0 is always just a store. Doing EE=1 also
requires us to check for pending interr
Some instructions can simply be replaced by load and store instructions to
or from the magic page.
This patch replaces often called instructions that fall into the above category.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- use kvm_patch_ins
---
arch/powerpc/kernel/kvm.c | 111 +
There is also a form of mtmsr where all bits need to be addressed. While the
PPC64 Linux kernel behaves resonably well here, on PPC32 we do not have an
L=1 form. It does mtmsr even for simple things like only changing EE.
So we need to hook into that one as well and check for a mask of bits that w
As we now have Book3s support for the magic page, we also need BookE to
join in on the party.
This patch implements generic magic page logic for BookE and specific
TLB logic for e500. I didn't have any 440 around, so I didn't dare to
blindly try and write up broken code.
Signed-off-by: Alexander
On Thu, Jul 01, 2010 at 03:04:54PM +1000, Michael Neuling wrote:
> > While running fs_racer test from LTP on a POWER6 box against latest
> > git(2.6.3
> 5-rc3-git4 - commitid 984bc9601f64fd)
> > came across the following warning followed by multiple oops.
> >
> > [ cut here ]-
On 07/01/2010 01:00 PM, Alexander Graf wrote:
But doesn't that mean that you still need to loop through all the hvas
that you want to invalidate?
It does.
Wouldn't it speed up dirty bitmap flushing
a lot if we'd just have a simple linked list of all sPTEs belonging to
that memslot?
T
On Thu, Jul 01, 2010 at 12:42:49PM +0200, Alexander Graf wrote:
>As we now have Book3s support for the magic page, we also need BookE to
>join in on the party.
>
>This patch implements generic magic page logic for BookE and specific
>TLB logic for e500. I didn't have any 440 around, so I didn't dar
Josh Boyer wrote:
> On Thu, Jul 01, 2010 at 12:42:49PM +0200, Alexander Graf wrote:
>
>> As we now have Book3s support for the magic page, we also need BookE to
>> join in on the party.
>>
>> This patch implements generic magic page logic for BookE and specific
>> TLB logic for e500. I didn't ha
Avi Kivity wrote:
> On 07/01/2010 01:00 PM, Alexander Graf wrote:
>>
>> But doesn't that mean that you still need to loop through all the hvas
>> that you want to invalidate?
>
> It does.
>
>> Wouldn't it speed up dirty bitmap flushing
>> a lot if we'd just have a simple linked list of all sPTEs
On 07/01/2010 03:28 PM, Alexander Graf wrote:
Wouldn't it speed up dirty bitmap flushing
a lot if we'd just have a simple linked list of all sPTEs belonging to
that memslot?
The complexity is O(pages_in_slot) + O(sptes_for_slot).
Usually, every page is mapped at least once, so s
Avi Kivity wrote:
> On 07/01/2010 03:28 PM, Alexander Graf wrote:
>>
>>>
Wouldn't it speed up dirty bitmap flushing
a lot if we'd just have a simple linked list of all sPTEs belonging to
that memslot?
>>> The complexity is O(pages_in_slot) + O(sptes_for_slot).
>>
On 07/01/2010 03:52 PM, Alexander Graf wrote:
Don't you use lazy spte updates?
We do, but given enough time, the guest will touch its entire memory.
Oh, so that's the major difference. On PPC we have the HTAB with a
fraction of all the mapped pages in it. We don't have a notion
On Wed, Jun 30, 2010 at 03:18:44PM +0200, Alexander Graf wrote:
> Book3s suffered from my really bad shadow MMU implementation so far. So
> I finally got around to implement a combined hash and list mechanism that
> allows for much faster lookup of mapped pages.
>
> To show that it really is faste
Alexander Graf wrote:
> Due to previous changes, the Book3S_32 guest MMU code didn't compile properly
> when enabling debugging.
>
> This patch repairs the broken code paths, making it possible to define
> DEBUG_MMU
> and friends again.
>
> Signed-off-by: Alexander Graf
>
Please also don't fo
On 07/01/2010 02:50 AM, Shawn Jin wrote:
Hi Scott,
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.?
If your CCSRBAR is 0xfa20, then pretty much anywhere you see
0xff0x change it to 0xfa2x.
I managed to proceed a little bit further
Dear All,
The Synopsis design ware core is task file orientated so the driver would
still need CONFIG_ATA_SFF.
I would be fixing the Kconfig file to make it dependent on the
CONFIG_ATA_SFF.
Regards,
Rup
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, July 0
On środa, 30 czerwca 2010 o 13:22:27 divya wrote:
> While running fs_racer test from LTP on a POWER6 box against latest
> git(2.6.35-rc3-git4 - commitid 984bc9601f64fd) came across the following
> warning followed by multiple oops.
>
I created a Bugzilla entry at
https://bugzilla.kernel.org/show
>>> How do I find the address, reg, and range for nodes like localbus,
>>> soc, eth0, cpm, serial etc.?
>
> If your CCSRBAR is 0xfa20, then pretty much anywhere you see 0xff0x
> change it to 0xfa2x.
I'm not sure about the range settings of 0xfe00. How do you get this?
local
On 07/01/2010 03:17 PM, Shawn Jin wrote:
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.?
If your CCSRBAR is 0xfa20, then pretty much anywhere you see 0xff0x
change it to 0xfa2x.
I'm not sure about the range settings of 0xfe00. Ho
On Tue, Jun 29, 2010 at 2:54 PM, Timur Tabi wrote:
> I'm adding support for a new e500-based board (the P1022DS), and in
> the process I've discovered that enabling CONFIG_NO_HZ (Tickless
> System / Dynamic Ticks) causes significant responsiveness problems on
> the serial console. When I type on
In message <20100701105907.gk22...@laptop> you wrote:
> On Thu, Jul 01, 2010 at 03:04:54PM +1000, Michael Neuling wrote:
> > > While running fs_racer test from LTP on a POWER6 box against latest git(2
.6.3
> > 5-rc3-git4 - commitid 984bc9601f64fd)
> > > came across the following warning followed by
On Thu, 2010-07-01 at 14:52 +0200, Alexander Graf wrote:
> Page ageing is difficult. The HTAB has a hardware set referenced bit,
> but we don't have a guarantee that the entry is still there when we look
> for it. Something else could have overwritten it by then, but the entry
> could still be ling
On Thu, 2010-07-01 at 16:42 +0300, Avi Kivity wrote:
> > So I think the only reasonable way to implement page ageing is to
> unmap
> > pages. And that's slow, because it means we have to map them again
> on
> > access. Bleks. Or we could look for the HTAB entry and only unmap
> them
> > if the entr
On Thu, 2010-07-01 at 16:55 -0500, Timur Tabi wrote:
> On Tue, Jun 29, 2010 at 2:54 PM, Timur Tabi wrote:
> > I'm adding support for a new e500-based board (the P1022DS), and in
> > the process I've discovered that enabling CONFIG_NO_HZ (Tickless
> > System / Dynamic Ticks) causes significant resp
On Jul 1, 2010, at 10:46 PM, "Mike Galbraith" wrote:
>
> Hi Timur,
>
> This has already fixed. Below is the final fix from tip.
Than Mike. I thought I was using the latest code, but I guess not.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozla
On Tue, 2010-06-29 at 14:54 -0500, Timur Tabi wrote:
> I'm adding support for a new e500-based board (the P1022DS), and in
> the process I've discovered that enabling CONFIG_NO_HZ (Tickless
> System / Dynamic Ticks) causes significant responsiveness problems on
> the serial console. When I type on
>-Original Message-
>From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On
>Behalf Of Benjamin Herrenschmidt
>Sent: Friday, July 02, 2010 1:47 PM
>To: Tabi Timur-B04825
>Cc: Linuxppc-dev Development
>Subject:
57 matches
Mail list logo
