On 06/01/2012 02:10 AM, Srivatsa S. Bhat wrote:
The per-cpu variable cpu_state is used in x86 and also used in other
architectures, to track the state of the cpu during bringup and hotplug.
Pull it out into generic code.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc
Greg,
Thanks so much for the comments and apologies for the delayed response.
> Don't we have something like this already for KVM and maybe Xen?
> virtio? Can't you use that code instead of a new block of code that
> is only used by vmware users? It has virtual pci devices which
> should give y
Hi Amit and Rusty,
I've been looking into the possibility of using the Virtio Console
Driver together with the remoteproc framework to communicate with
ST-Ericsson modem over shared memory.
It seems like Virtio Console would be a good fit, except for a issue
with buffer allocation. Due to HW limi
>>> On 01.06.12 at 17:13, "Srivatsa S. Bhat"
wrote:
> On 06/01/2012 06:29 PM, Jan Beulich wrote:
>
> On 01.06.12 at 11:11, "Srivatsa S. Bhat"
>
>> wrote:
>>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>>> is invoked in the cpu down path, whereas cpu_bri
On 06/01/2012 06:29 PM, Jan Beulich wrote:
On 01.06.12 at 11:11, "Srivatsa S. Bhat"
> wrote:
>> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
>> is invoked in the cpu down path, whereas cpu_bringup() (as the name
>> suggests) is useful in the cpu bringup path.
>>> On 01.06.12 at 11:11, "Srivatsa S. Bhat"
wrote:
> xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
> is invoked in the cpu down path, whereas cpu_bringup() (as the name
> suggests) is useful in the cpu bringup path.
This might not be correct - the code as it is wi
The per-cpu variable cpu_state is used in x86 and also used in other
architectures, to track the state of the cpu during bringup and hotplug.
Pull it out into generic code.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: Paul Mundt
Cc: Chris Metcalf
Cc: Thomas Gl
Holding the vblk->lock across kick causes poor scalability in SMP
guests. If one CPU is doing virtqueue kick and another CPU touches the
vblk->lock it will have to spin until virtqueue kick completes.
This patch reduces system% CPU utilization in SMP guests that are
running multithreaded I/O-boun
Convert xen to use the generic framework to boot secondary CPUs.
Cc: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: xen-de...@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-ker...@vger
xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead()
is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests)
is useful in the cpu bringup path.
Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking
on to the generic SMP booting
On Fri, May 25, 2012 at 04:03:27PM +0800, Asias He wrote:
> Block layer will allocate a spinlock for the queue if the driver does
> not provide one in blk_init_queue().
>
> The reason to use the internal spinlock is that blk_cleanup_queue() will
> switch to use the internal spinlock in the cleanup
On Fri, Jun 1, 2012 at 5:38 AM, Asias He wrote:
> On 05/30/2012 09:19 PM, Stefan Hajnoczi wrote:
> Could you use vblk->disk->queue->queue_lock to reference the lock so that
> this patch will work on top of this one:
>
> virtio-blk: Use block layer provided spinlock
Absolutely. I'll rebased on
On Fri, Jun 1, 2012 at 10:31 AM, Sjur BRENDELAND
wrote:
> if (virtio_has_feature(vdev, VIRTIO_CONSOLE_USE_DMA_MEM)) {
> dma_addr_t dma;
> buf = dma_alloc_coherent(dev, size, &dma, GFP_KERNEL);
> } else
> buf = kmalloc(count, GFP_KERNEL);
13 matches
Mail list logo
