> > > Cc: sta...@kernle.org
> > > Signed-off-by: Kashyap Desai
> > > ---
> > > diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
> > > b/drivers/scsi/mpt2sas/mpt2sas_base.c
> > > index efa0255..5778334 100644
> > > --- a/drivers/scsi/mpt2sas/mpt2sas_base.c
> > > +++ b/drivers/scsi/mpt2sas/mpt2sas
On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
> On Wed, 2011-05-04 at 17:23 +0530, Kashyap, Desai wrote:
> > The following code seems to be there in
> > /usr/src/linux/arch/x86/include/asm/io.h.
> > This is not going to work.
> >
> > static inline void writeq(__u64 val, volatile
On Tue, 2011-05-17 at 22:15 -0600, Matthew Wilcox wrote:
> On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
> > On Wed, 2011-05-04 at 17:23 +0530, Kashyap, Desai wrote:
> > > The following code seems to be there in
> > > /usr/src/linux/arch/x86/include/asm/io.h.
> > > This is not go
Previously, these macros hardcoded THREAD_EVR0 as the base of the save
area, relative to the base register passed. This base offset is now
passed as a separate macro parameter, allowing reuse with other SPE
save areas, such as used by KVM.
Signed-off-by: Scott Wood
---
This is a resending of htt
From: yu liu
giveup_spe() saves the SPE state which is protected by MSR[SPE].
However, modifying SPEFSCR does not trap when MSR[SPE]=0.
And since SPEFSCR is already saved/restored in _switch(),
not all the callers want to save SPEFSCR again.
Thus, saving SPEFSCR should not belong to giveup_spe().
On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
> Ben,
>
> Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
> mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
> sequence after "mpic: requesting IPIs..."
>
> When the system comes up, only one core
Hi,
On Mon, May 16, 2011 at 6:38 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2011-05-16 at 16:37 +1000, Michael Neuling wrote:
>> > what is the best book to learn assembly and architecture .
>>
Assuming you have a powerpc compiler available you can use the -S
option to produce assembly
* James Morris wrote:
> On Tue, 17 May 2011, Ingo Molnar wrote:
>
> > I'm not sure i get your point.
>
> Your example was not complete as described. After an apparently simple
> specification, you've since added several qualifiers and assumptions, [...]
I havent added any qualifiers really
On Tue, May 17, 2011 at 03:05:12PM -0300, Marcelo Tosatti wrote:
> >
> > - ret = __kvmppc_vcpu_entry(kvm_run, vcpu);
> > + kvm_guest_enter();
>
>
> kvm_guest_enter should run with interrupts disabled.
Its fine, please ignore message.
___
Linuxpp
On Wed, May 11, 2011 at 08:43:31PM +1000, Paul Mackerras wrote:
> >From 964ee93b2d728e4fb16ae66eaceb6e912bf114ad Mon Sep 17 00:00:00 2001
> From: Paul Mackerras
> Date: Tue, 10 May 2011 22:23:18 +1000
> Subject: [PATCH 08/13] kvm/powerpc: Move guest enter/exit down into
> subarch-specific code
>
thanks.
regards,
sha
> From: mi...@neuling.org
> To: b...@kernel.crashing.org
> CC: sha_...@hotmail.com; linuxppc-dev@lists.ozlabs.org
> Subject: Re: book to learn ppc assembly and architecture
> Date: Tue, 17 May 2011 09:43:35 +1000
>
> In message <1305589123.2781.15.camel@pasglop> you wrote
Ben,
Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
sequence after "mpic: requesting IPIs..."
When the system comes up, only one core shows in /proc/cpuinfo. Later
on, lots of messages appear like the foll
On Tue, 17 May 2011, Ingo Molnar wrote:
> I'm not sure i get your point.
Your example was not complete as described. After an apparently simple
specification, you've since added several qualifiers and assumptions, and
I still doubt that it's complete.
A higher level goal would look like
"All
* Steven Rostedt wrote:
> On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
> > * Steven Rostedt wrote:
> >
> > > On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
> > > > * Steven Rostedt wrote:
> > > >
> > > > > I'm a bit nervous about the 'active' role of (trace_)events, because
* James Morris wrote:
> On Mon, 16 May 2011, Ingo Molnar wrote:
>
> > > Not really.
> > >
> > > Firstly, what is the security goal of these restrictions? [...]
> >
> > To do what i described above? Namely:
> >
> > " Sandboxed code should only be allowed to open files in /home/sandbox/,
> >
On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
> * Steven Rostedt wrote:
>
> > On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
> > > * Steven Rostedt wrote:
> > >
> > > > I'm a bit nervous about the 'active' role of (trace_)events, because of
> > > > the
> > > > way multiple call
* Will Drewry wrote:
> > This is *far* more generic still yields the same short-term end result as
> > far as your sandboxing is concerned.
>
> Almost :/ [...]
Hey that's a pretty good result from a subsystem that was not written with your
usecase in mind *at all* ;-)
> [...] I still need
* Steven Rostedt wrote:
> On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
> > * Steven Rostedt wrote:
> >
> > > I'm a bit nervous about the 'active' role of (trace_)events, because of
> > > the
> > > way multiple callbacks can be registered. How would:
> > >
> > > err = event_x();
>
On 05/17/2011 02:38 PM, Alexander Graf wrote:
>
> What would be the path for these patches to get upstream? Would this
> stuff normally go through Avi's tree? There is a bit of a
> complication in that they are based on Ben's next branch. Would Avi
> pull Ben's next branch, or would they g
Am 17.05.2011 um 13:15 schrieb Paul Mackerras :
> On Tue, May 17, 2011 at 11:46:34AM +0200, Alexander Graf wrote:
>
>> Very nice patches indeed :). Is there any way I can test them? I
>> don't like pulling code that I couldn't run anywhere yet.
>
> I can understand that, but unfortunately ther
Am 17.05.2011 um 12:44 schrieb Paul Mackerras :
> On Tue, May 17, 2011 at 10:21:56AM +0200, Alexander Graf wrote:
>>
>> On 11.05.2011, at 12:46, Paul Mackerras wrote:
>>
>>> -#define KVM_MAX_VCPUS 1
>>> +#define KVM_MAX_VCPUSNR_CPUS
>>> +#define KVM_THREADS_PER_CORE4
>>
>> So what
On Tue, May 17, 2011 at 09:54:35AM +0200, Alexander Graf wrote:
> Not sure I like the name - when is it used? :)
When the real-mode hcall handler decides it can't handle the hcall and
wants to pass it up.
> Also, if it's not in the PAPR, the guest should never receive it, right?
Right. It's pu
On Tue, May 17, 2011 at 10:21:56AM +0200, Alexander Graf wrote:
>
> On 11.05.2011, at 12:46, Paul Mackerras wrote:
>
> > -#define KVM_MAX_VCPUS 1
> > +#define KVM_MAX_VCPUS NR_CPUS
> > +#define KVM_THREADS_PER_CORE 4
>
> So what if POWER8 (or whatever it will be called) comes
On Tue, May 17, 2011 at 11:46:34AM +0200, Alexander Graf wrote:
> Very nice patches indeed :). Is there any way I can test them? I
> don't like pulling code that I couldn't run anywhere yet.
I can understand that, but unfortunately there are no machines
available outside of IBM at this stage that
On 16.05.2011, at 07:58, Paul Mackerras wrote:
> On Sun, May 15, 2011 at 11:58:12PM +0200, Alexander Graf wrote:
>>
>> On 11.05.2011, at 12:44, Paul Mackerras wrote:
>
>>> +#ifdef CONFIG_KVM_BOOK3S_NONHV
>>
>> I really liked how you called the .c file _pr - why call it NONHV now?
>
> I agree,
On 11.05.2011, at 12:34, Paul Mackerras wrote:
> The following series of patches enable KVM to exploit the hardware
> hypervisor mode on 64-bit Power ISA Book3S machines. At present only
> POWER7 is supported, but it would be easy to add other processors.
>
> Running the KVM host in hypervisor
On 17.05.2011, at 11:35, Benjamin Herrenschmidt wrote:
> On Tue, 2011-05-17 at 11:31 +0200, Alexander Graf wrote:
>> On 17.05.2011, at 11:11, Benjamin Herrenschmidt wrote:
>>
>>> On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote:
I'm not sure I fully understand how this is supposed to
On Tue, 2011-05-17 at 11:31 +0200, Alexander Graf wrote:
> On 17.05.2011, at 11:11, Benjamin Herrenschmidt wrote:
>
> > On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote:
> >> I'm not sure I fully understand how this is supposed to work. If the
> >> tables are kept inside the kernel, how doe
On 17.05.2011, at 11:11, Benjamin Herrenschmidt wrote:
> On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote:
>> I'm not sure I fully understand how this is supposed to work. If the
>> tables are kept inside the kernel, how does userspace get to know
>> where to DMA to?
>
> The guest gets a
On Tue, 2011-05-17 at 10:01 +0200, Alexander Graf wrote:
> I'm not sure I fully understand how this is supposed to work. If the
> tables are kept inside the kernel, how does userspace get to know
> where to DMA to?
The guest gets a dma range from the device-tree which is the range of
device-side d
On 11.05.2011, at 12:46, Paul Mackerras wrote:
> This lifts the restriction that book3s_hv guests can only run one
> hardware thread per core, and allows them to use up to 4 threads
> per core on POWER7. The host still has to run single-threaded.
>
> This capability is advertised to qemu throug
On 11.05.2011, at 12:46, Paul Mackerras wrote:
> From: David Gibson
>
> This improves I/O performance for guests using the PAPR paravirtualization
> interface by making the H_PUT_TCE hcall faster, by implementing it in
> real mode. H_PUT_TCE is used for updating virtual IOMMU tables, and is
>
On 11.05.2011, at 12:45, Paul Mackerras wrote:
> This adds the infrastructure for handling PAPR hcalls in the kernel,
> either early in the guest exit path while we are still in real mode,
> or later once the MMU has been turned back on and we are in the full
> kernel context. The advantage of h
33 matches
Mail list logo
