refer to orignal plan posted by Marcelo Tosatti,
http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg04315.html
These patches protect DeviceState's rd from reclaimer. It is neccessary
when no qemu_global_lock protects between them.
--
To unsubscribe from this list: send the line "unsubscribe k
From: Liu Ping Fan
When guest confirm the removal of device, we should
--unmap from MemoryRegion view
--isolated from device tree view
Signed-off-by: Liu Ping Fan
---
hw/acpi_piix4.c |4 ++--
hw/qdev.c | 28
hw/qdev.h |3 ++-
3 files changed
From: Liu Ping Fan
acquire device's refcnt with qemu_device_tree_mutex rwlock, so we
can safely handle it when mmio dispatch.
If in radix-tree, leaf is subpage, then move further step to acquire
opaque which is the type --DeiveState.
Signed-off-by: Liu Ping Fan
---
exec.c |
From: Liu Ping Fan
rwlock:
qemu_device_tree_mutex
rd side:
--device_del(destruction of device will be postphoned until unplug
ack from guest),
--pci hot-unplug
--iteration (qdev_reset_all)
wr side:
--device_add
Signed-off-by: Liu Ping Fan
---
hw/pci-hotplug.c |4
hw
From: Liu Ping Fan
iohandler/bh/timer may use DeviceState when its refcnt=0,
postpone the reclaimer till they have done with it.
Signed-off-by: Liu Ping Fan
---
include/qemu/object.h |2 +-
main-loop.c |4
main-loop.h |2 ++
qemu-tool.c |4
From: Liu Ping Fan
Signed-off-by: Liu Ping Fan
---
hw/e1000.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/e1000.c b/hw/e1000.c
index 4573f13..4c1e141 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1192,6 +1192,18 @@ e1000_cleanup(VLANClientState *nc
On Wed, Jul 25, 2012 at 3:43 PM, Stefan Hajnoczi wrote:
> On Wed, Jul 25, 2012 at 4:31 AM, Liu Ping Fan wrote:
>> @@ -3396,13 +3420,25 @@ void cpu_physical_memory_rw(target_phys_addr_t addr,
>> uint8_t *buf,
>> uint32_t val;
>> target_phys_addr_t page;
On Wed, Jul 25, 2012 at 3:37 PM, Paolo Bonzini wrote:
> Il 25/07/2012 09:03, Stefan Hajnoczi ha scritto:
>> From: Liu Ping Fan
>>
>> iohandler/bh/timer may use DeviceState when its refcnt=0,
>
> It's not clear how to me. The only reference to devices from an
&g
On Wed, Jul 25, 2012 at 3:03 PM, Stefan Hajnoczi wrote:
> On Wed, Jul 25, 2012 at 4:31 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> iohandler/bh/timer may use DeviceState when its refcnt=0,
>> postpone the reclaimer till they have done with it.
>&g
On Wed, Jul 25, 2012 at 5:08 PM, Paolo Bonzini wrote:
> Il 25/07/2012 05:31, Liu Ping Fan ha scritto:
>> From: Liu Ping Fan
>>
>> rwlock:
>> qemu_device_tree_mutex
>>
>> rd side:
>> --device_del(destruction of device will be postphoned until
On Wed, Jul 25, 2012 at 5:18 PM, Paolo Bonzini wrote:
> Il 25/07/2012 10:12, liu ping fan ha scritto:
>>>> >> +qemu_rwlock_rdlock_devtree();
>>>> >> section = phys_page_find(page >> TARGET_PAGE_BITS);
>>&g
On Wed, Jul 25, 2012 at 8:27 PM, Avi Kivity wrote:
> On 07/25/2012 01:58 PM, Avi Kivity wrote:
>>> while (len > 0) {
>>> page = addr & TARGET_PAGE_MASK;
>>> l = (page + TARGET_PAGE_SIZE) - addr;
>>> if (l > len)
>>> l = len;
>>> +
>>> +qemu_rwlo
On Thu, Jul 26, 2012 at 9:00 PM, Avi Kivity wrote:
> On 07/26/2012 03:56 PM, liu ping fan wrote:
>> On Wed, Jul 25, 2012 at 5:08 PM, Paolo Bonzini wrote:
>>> Il 25/07/2012 05:31, Liu Ping Fan ha scritto:
>>>> From: Liu Ping Fan
>>>>
>>>> r
On Thu, Jul 26, 2012 at 9:15 PM, Avi Kivity wrote:
> On 07/26/2012 04:14 PM, liu ping fan wrote:
>>>
>>> From the description above, I don't see why it can't be a mutex.
>>>
>> Searching in the device tree (or MemoryRegion view) can be often in
>
From: Liu Ping Fan
Signed-off-by: Liu Ping Fan
---
include/qemu/object.h |3 ++-
qom/object.c | 13 +
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/include/qemu/object.h b/include/qemu/object.h
index 8b17776..58db9d0 100644
--- a/include/qemu
From: Liu Ping Fan
Collect unused object and release them at caller demand.
Signed-off-by: Liu Ping Fan
---
include/qemu/reclaimer.h | 28 ++
main-loop.c |5
qemu-tool.c |5
qom/Makefile.objs|2 +-
qom/reclaimer.c
From: Liu Ping Fan
Using mem_map_lock to protect among updaters. So we can get the intact
snapshot of mem topology -- FlatView & radix-tree.
Signed-off-by: Liu Ping Fan
---
exec.c |3 +++
memory.c | 22 ++
memory.h |2 ++
3 files changed, 27 insertions(+
background:
refer to orignal plan posted by Marcelo Tosatti,
http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg04315.html
prev version:
https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg03312.html
changes v1->v2
--introduce atomic ops
--introduce ref cnt for MemoryRegion
--make mem
From: Liu Ping Fan
The types of referred object by MemoryRegion are variable, ex,
another mr, DeviceState, or other struct defined by drivers.
So the refer/unrefer may be different by drivers.
Using this ops, we can mange the backend object.
Signed-off-by: Liu Ping Fan
---
hw/ide/piix.c
From: Liu Ping Fan
Using refcnt for mr, so we can separate mr's life cycle management
from refered object.
When mr->ref 0->1, inc the refered object.
When mr->ref 1->0, dec the refered object.
The refered object can be DeviceStae, another mr, or other opaque.
Signed-off
From: Liu Ping Fan
If out of global lock, we will be challenged by SMP in low level,
so need atomic ops.
This file is heavily copied from kernel. Currently, only x86 atomic ops
included, and will be extended for other arch for future.
Signed-off-by: Liu Ping Fan
---
include/qemu/atomic.h
From: Liu Ping Fan
memory_region_{add,del}_subregion will inc/dec mr's refcnt.
Signed-off-by: Liu Ping Fan
---
memory.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/memory.c b/memory.c
index 5dc8b59..2eaa2fc 100644
--- a/memory.c
+++ b/memory.c
@@ -1
From: Liu Ping Fan
PhysMap contain the flatview and radix-tree view, they are snapshot
of system topology and should be consistent. With PhysMap, we can
swap the pointer when updating and achieve the atomic.
Signed-off-by: Liu Ping Fan
---
exec.c |8
memory.c | 33
From: Liu Ping Fan
Flatview and radix view are all under the protection of pointer.
And this make sure the change of them seem to be atomic!
The mr accessed by radix-tree leaf or flatview will be reclaimed
after the prev PhysMap not in use any longer
Signed-off-by: Liu Ping Fan
---
exec.c
From: Liu Ping Fan
Change tcg code to use PhysMap.
This is separated from the prev patch for review purpose. Should be
merged into prev one.
Signed-off-by: Liu Ping Fan
---
exec.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/exec.c b
From: Liu Ping Fan
Signed-off-by: Liu Ping Fan
---
cpus.c | 12
main-loop.h |3 +++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/cpus.c b/cpus.c
index b182b3d..a734b36 100644
--- a/cpus.c
+++ b/cpus.c
@@ -611,6 +611,7 @@ static void
From: Liu Ping Fan
lock:
qemu_device_tree_mutex
competitors:
--device_del(destruction of device will be postphoned until unplug
ack from guest),
--pci hot-unplug
--iteration (qdev_reset_all)
--device_add
Signed-off-by: Liu Ping Fan
---
hw/pci-hotplug.c |4
hw/qdev
From: Liu Ping Fan
When guest confirm the removal of device, we should
--unmap from MemoryRegion view
--isolated from device tree view
Signed-off-by: Liu Ping Fan
---
hw/acpi_piix4.c |4 ++--
hw/pci.c| 13 -
hw/pci.h|2 ++
hw/qdev.c | 28
From: Liu Ping Fan
iohandler/bh/timer may use DeviceState when its refcnt=0,
postpone the reclaimer till they have done with it.
Signed-off-by: Liu Ping Fan
---
qom/object.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index
From: Liu Ping Fan
Signed-off-by: Liu Ping Fan
---
hw/e1000.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/e1000.c b/hw/e1000.c
index 4573f13..fa71455 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1192,6 +1192,13 @@ e1000_cleanup(VLANClientState *nc)
s
On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity wrote:
> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Using refcnt for mr, so we can separate mr's life cycle management
>> from refered object.
>> When mr->ref 0->1, inc the ref
On Wed, Aug 8, 2012 at 5:42 PM, Avi Kivity wrote:
> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>
> Please explain the motivation. AFAICT, the big qemu lock is sufficient.
>
Oh, this is one of the series locks for the removal of big qemu lock
On Wed, Aug 8, 2012 at 5:41 PM, Paolo Bonzini wrote:
> Il 08/08/2012 08:25, Liu Ping Fan ha scritto:
>> From: Liu Ping Fan
>>
>> Signed-off-by: Liu Ping Fan
>> ---
>> cpus.c | 12
>> main-loop.h |3 +++
>> 2 files changed
On Wed, Aug 8, 2012 at 5:56 PM, Paolo Bonzini wrote:
> Il 08/08/2012 08:25, Liu Ping Fan ha scritto:
>>
>> +static void
>> +pci_e1000_unmap(PCIDevice *p)
>> +{
>> +/* DO NOT FREE anything!until refcnt=0 */
>> +/* isolate from memory view */
On Wed, Aug 8, 2012 at 5:52 PM, Paolo Bonzini wrote:
> Il 08/08/2012 08:25, Liu Ping Fan ha scritto:
>> +void qdev_unplug_complete(DeviceState *dev, Error **errp)
>> +{
>> +/* isolate from mem view */
>> +qdev_unmap(dev);
>> +qemu_lock_devtree();
&g
On Thu, Aug 9, 2012 at 3:17 AM, Blue Swirl wrote:
> On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Using mem_map_lock to protect among updaters. So we can get the intact
>> snapshot of mem topology -- FlatView & radix-tree.
&g
On Wed, Aug 8, 2012 at 5:13 PM, Avi Kivity wrote:
> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Using mem_map_lock to protect among updaters. So we can get the intact
>> snapshot of mem topology -- FlatView & radix-tree.
&g
On Thu, Aug 9, 2012 at 3:18 AM, Blue Swirl wrote:
> On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> PhysMap contain the flatview and radix-tree view, they are snapshot
>> of system topology and should be consistent. With PhysMap, we c
On Thu, Aug 9, 2012 at 3:23 AM, Blue Swirl wrote:
> On Wed, Aug 8, 2012 at 6:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Flatview and radix view are all under the protection of pointer.
>> And this make sure the change of them seem to be atomic!
>>
On Wed, Aug 8, 2012 at 5:15 PM, Avi Kivity wrote:
> On 08/08/2012 12:07 PM, Paolo Bonzini wrote:
>> Il 08/08/2012 11:05, Avi Kivity ha scritto:
>>>> > From: Liu Ping Fan
>>>> >
>>>> > Collect unused object and release them at caller demand.
&
On Wed, Aug 8, 2012 at 5:35 PM, Paolo Bonzini wrote:
> Il 08/08/2012 08:25, Liu Ping Fan ha scritto:
>> From: Liu Ping Fan
>>
>> Collect unused object and release them at caller demand.
>>
>> Signed-off-by: Liu Ping Fan
>> ---
>> include/qemu/recla
On Thu, Aug 9, 2012 at 4:00 PM, Paolo Bonzini wrote:
> Il 09/08/2012 09:28, liu ping fan ha scritto:
>>> > VCPU threadI/O thread
>>> > =
>>> > get MMIO request
&
On Thu, Aug 9, 2012 at 3:40 PM, Paolo Bonzini wrote:
> Il 09/08/2012 09:28, liu ping fan ha scritto:
>>>> >> +static void
>>>> >> +pci_e1000_unmap(PCIDevice *p)
>>>> >> +{
>>>> >> +/* DO NOT FREE anything!until refcnt
On Thu, Aug 9, 2012 at 4:18 PM, Avi Kivity wrote:
> On 08/09/2012 10:49 AM, Paolo Bonzini wrote:
>> Il 09/08/2012 09:33, liu ping fan ha scritto:
>>> Yes, it is to defer destructors.
>>> See 0009-memory-prepare-flatview-and-radix-tree-for-rcu-style.patch
>>>
On Thu, Aug 9, 2012 at 4:38 PM, Avi Kivity wrote:
> On 08/09/2012 10:27 AM, liu ping fan wrote:
>> On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity wrote:
>>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>>> From: Liu Ping Fan
>>>>
>>>> U
On Thu, Aug 9, 2012 at 4:24 PM, Avi Kivity wrote:
> On 08/09/2012 10:28 AM, liu ping fan wrote:
>>>
>>> Seems to me that nothing in memory.c can susceptible to races. It must
>>> already be called under the big qemu lock, and with the exception of
>>>
On Wed, Aug 8, 2012 at 5:41 PM, Avi Kivity wrote:
> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Flatview and radix view are all under the protection of pointer.
>> And this make sure the change of them seem to be atomic!
>>
>>
On Sat, Aug 11, 2012 at 9:58 AM, liu ping fan wrote:
> On Wed, Aug 8, 2012 at 5:41 PM, Avi Kivity wrote:
>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> Flatview and radix view are all under the protection of pointer.
>>&g
On Mon, Sep 3, 2012 at 7:48 PM, Avi Kivity wrote:
> On 09/03/2012 09:44 AM, Juan Quintela wrote:
>>
>> Hi
>>
>> Please send in any agenda items you are interested in covering.
>
> - protecting MemoryRegion::opaque during dispatch
>
> I'm guessing Ping won't make it due to timezone problems. Jan,
On Tue, Sep 4, 2012 at 4:21 PM, Avi Kivity wrote:
> On 09/04/2012 11:17 AM, liu ping fan wrote:
>> On Mon, Sep 3, 2012 at 7:48 PM, Avi Kivity wrote:
>>> On 09/03/2012 09:44 AM, Juan Quintela wrote:
>>>>
>>>> Hi
>>>>
>>>&
On Wed, Oct 5, 2011 at 7:01 PM, Jan Kiszka wrote:
> On 2011-10-05 12:26, liu ping fan wrote:
>>> > And make the creation of apic as part of cpu initialization, so
>>>> apic's state has been ready, before setting kvm_apic.
>>>
>>> There is no k
On 10/6/11, Jan Kiszka wrote:
> On 2011-10-06 03:13, liu ping fan wrote:
>> On Wed, Oct 5, 2011 at 7:01 PM, Jan Kiszka wrote:
>>> On 2011-10-05 12:26, liu ping fan wrote:
>>>>> > And make the creation of apic as part of cpu initialization, so
>>>&g
A series of patches from kvm, qemu to guest. These patches will finally enable
vcpu destruction in kvm instance and let vcpu thread exit in qemu.
Currently, the vcpu online feature enables the dynamical creation of vcpu and
vcpu thread, while the offline feature can not destruct the vcpu and le
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu as a refer to kvm, and then vcpu MUST and CAN be
destroyed before kvm's destroy. Qemu will take advantage of this to
exit the vcpu thread if the thread is no longer in use by guest.
S
From: Liu Ping Fan
The vcpu can be safely released when
--1.guest tells us that the vcpu is not needed any longer.
--2.vcpu hits the last instruction _halt_
If both of the conditions are satisfied, kvm exits to userspace
with the reason vcpu dead. So the user thread can exit safely.
Signed-off
From: Liu Ping Fan
The guest has different cpu logic id from qemu, but they have the
same phyid. When cpu phyid is told by guest, we need to obtain
the corresponding CPUState.
Signed-off-by: Liu Ping Fan
---
target-i386/cpu.h|2 ++
target-i386/helper.c | 12
2 files
From: Liu Ping Fan
When exiting from vcpu thread, the CPUState must be freed firstly.
And the handling process is an arch related.
Signed-off-by: Liu Ping Fan
---
hw/apic.c|4
target-i386/cpu.h|3 +++
target-i386/helper.c |8
3 files changed, 15
From: Liu Ping Fan
This device's driver in guest can get vcpu dead event and notify
qemu through the device.
Signed-off-by: Liu Ping Fan
---
Makefile.target |1 +
hw/pc_piix.c |1 +
hw/pci.c | 22 +++
hw/pci.h |1 +
hw/pci_cpustate.c |
From: Liu Ping Fan
When guest driver tell us that the vcpu is no longer needed,
qemu can release the vcpu and finally exit vcpu thread
Signed-off-by: Liu Ping Fan
---
cpu-defs.h|5 +
cpus.c| 21 +
hmp-commands.hx |2 +-
hw/acpi_piix4.c
From: Liu Ping Fan
Temporary patch for qemu to compile. Normally the headers should be
copied from kernel.
Signed-off-by: Liu Ping Fan
---
kvm/include/linux/kvm.h |9 -
linux-headers/linux/kvm.h |9 +
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a
From: Liu Ping Fan
A driver for qemu device "cpustate". This driver catch the guest
CPU_DEAD event, and notify host.
Signed-off-by: Liu Ping Fan
---
drivers/virtio/Kconfig |6 ++
drivers/virtio/Makefile|1 +
drivers/virtio/cpustate_stu
On Sat, Nov 26, 2011 at 1:54 AM, Jan Kiszka wrote:
> On 2011-11-25 00:35, Liu Ping Fan wrote:
>> A series of patches from kvm, qemu to guest. These patches will finally
>> enable vcpu destruction in kvm instance and let vcpu thread exit in qemu.
>>
>> Currently, the
On Sun, Nov 27, 2011 at 6:50 PM, Gleb Natapov wrote:
> On Sun, Nov 27, 2011 at 12:36:55PM +0200, Avi Kivity wrote:
>> On 11/27/2011 04:42 AM, Liu Ping Fan wrote:
>> > From: Liu Ping Fan
>> >
>> > The vcpu can be safely released when
>> > --1.guest te
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu's destruction taken when its refcnt is zero,
and then vcpu MUST and CAN be destroyed before kvm's destroy.
Signed-off-by: Liu Ping Fan
---
arch/x86/kvm/i8254.c | 14 ++
On Sat, Dec 3, 2011 at 2:26 AM, Jan Kiszka wrote:
> On 2011-12-02 07:26, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction taken when its refcnt is zero,
On Sun, Dec 4, 2011 at 6:23 PM, Avi Kivity wrote:
> On 12/02/2011 08:26 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction taken when its refcnt is zero,
On Sun, Dec 4, 2011 at 8:10 PM, Gleb Natapov wrote:
> On Sun, Dec 04, 2011 at 07:53:37PM +0800, Liu ping fan wrote:
>> On Sat, Dec 3, 2011 at 2:26 AM, Jan Kiszka wrote:
>> > On 2011-12-02 07:26, Liu Ping Fan wrote:
>> >> From: Liu Ping Fan
>> >>
>>
On Mon, Dec 5, 2011 at 4:41 PM, Gleb Natapov wrote:
> On Mon, Dec 05, 2011 at 01:39:37PM +0800, Liu ping fan wrote:
>> On Sun, Dec 4, 2011 at 8:10 PM, Gleb Natapov wrote:
>> > On Sun, Dec 04, 2011 at 07:53:37PM +0800, Liu ping fan wrote:
>> >> On Sat, Dec 3, 2011
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu's destruction taken when its refcnt is zero,
and then vcpu MUST and CAN be destroyed before kvm's destroy.
Signed-off-by: Liu Ping Fan
---
arch/x86/kvm/i8254.c | 10 ++
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu's destruction taken when its refcnt is zero,
and then vcpu MUST and CAN be destroyed before kvm's destroy.
Signed-off-by: Liu Ping Fan
---
arch/x86/kvm/i8254.c | 10 ++
On Mon, Dec 12, 2011 at 8:54 PM, Gleb Natapov wrote:
> On Mon, Dec 12, 2011 at 10:41:23AM +0800, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction taken when
On Tue, Dec 13, 2011 at 7:36 PM, Marcelo Tosatti wrote:
> On Mon, Dec 12, 2011 at 10:41:23AM +0800, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction taken when
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu's destruction before kvm instance, so vcpu MUST
and CAN be destroyed before kvm's destroy.
Signed-off-by: Liu Ping Fan
---
arch/x86/kvm/i8254.c |8 ++-
arch/x86/k
On Thu, Dec 15, 2011 at 1:33 PM, Xiao Guangrong
wrote:
> On 12/15/2011 12:28 PM, Liu Ping Fan wrote:
>
>
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -1833,11 +1833,12 @@ static void kvm_mmu_put_page(struct kvm_mmu_page
>> *sp, u6
2011/12/15 Gleb Natapov :
> On Thu, Dec 15, 2011 at 11:21:37AM +0800, Liu ping fan wrote:
>> On Tue, Dec 13, 2011 at 7:36 PM, Marcelo Tosatti wrote:
>> > On Mon, Dec 12, 2011 at 10:41:23AM +0800, Liu Ping Fan wrote:
>> >> From: Liu Ping Fan
>> >>
>>
On Thu, Dec 15, 2011 at 5:10 PM, Gleb Natapov wrote:
> On Thu, Dec 15, 2011 at 12:28:48PM +0800, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction before kvm i
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu's destruction before kvm instance, so vcpu MUST
and CAN be destroyed before kvm's destroy.
Signed-off-by: Liu Ping Fan
---
arch/x86/kvm/i8254.c | 10 +++--
arch/x86/k
2011/12/15 Takuya Yoshikawa :
> (2011/12/15 13:28), Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction before kvm instance, so vcpu MUST
>> and CAN be destroy
On Mon, Dec 26, 2011 at 7:09 PM, Gleb Natapov wrote:
> On Sat, Dec 17, 2011 at 11:19:35AM +0800, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction before kvm i
From: Liu Ping Fan
Currently, vcpu can be destructed only when kvm instance destroyed.
Change this to vcpu's destruction before kvm instance, so vcpu MUST
and CAN be destroyed before kvm's destroy.
Signed-off-by: Liu Ping Fan
---
arch/x86/kvm/i8254.c | 10 +++--
arch/x86/k
2011/12/27 Takuya Yoshikawa :
> (2011/12/27 17:38), Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu can be destructed only when kvm instance destroyed.
>> Change this to vcpu's destruction before kvm instance, so vcpu MUST
>> and CAN be destro
On Wed, Dec 28, 2011 at 5:53 PM, Avi Kivity wrote:
> On 12/28/2011 08:54 AM, Liu ping fan wrote:
>> >>
>> >> struct kvm_vcpu {
>> >> struct kvm *kvm;
>> >> + struct list_head list;
>> >> #ifdef CONFIG_PREEMPT
On Thu, Dec 29, 2011 at 10:31 PM, Avi Kivity wrote:
> On 12/29/2011 04:03 PM, Liu ping fan wrote:
>> > Why do we want an independent grace period, is hotunplugging a vcpu that
>> > much different from hotunplugging memory?
>> >
>> I thought that if less
From: Liu Ping Fan
Currently, vcpu will be destructed only after kvm instance is
destroyed. This result to vcpu keep idle in kernel, but can not
be freed when it is unplugged in guest.
Change this to vcpu's destruction before kvm instance, so vcpu MUST
and CAN be destroyed before kvm ins
Hi,
Could anybody give some description about the implement of hyercall in
kvm? Or give some links about it?
Thanks,
ping fan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
On Thu, Jan 12, 2012 at 5:21 PM, Stefan Hajnoczi wrote:
> On Thu, Jan 12, 2012 at 4:38 AM, Liu ping fan wrote:
>> Could anybody give some description about the implement of hyercall in
>> kvm? Or give some links about it?
>
> Try git grep hypercall arch/x86/kvm.
>
>
On Fri, Jan 13, 2012 at 6:11 PM, Stefan Hajnoczi wrote:
> On Fri, Jan 13, 2012 at 7:45 AM, Liu ping fan wrote:
>> On Thu, Jan 12, 2012 at 5:21 PM, Stefan Hajnoczi wrote:
>>> On Thu, Jan 12, 2012 at 4:38 AM, Liu ping fan wrote:
>>>> Could anybody give some desc
On Thu, Jan 12, 2012 at 8:37 PM, Avi Kivity wrote:
> On 01/07/2012 04:55 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu will be destructed only after kvm instance is
>> destroyed. This result to vcpu keep idle in kernel, but can not
>> be fr
Hi,
During reading the vhost-net code, I find the following,
static void handle_tx(struct vhost_net *net)
{
struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
unsigned out, in, s;
int head;
struct msghdr msg = {
.msg_name = NULL,
Oh, got it. It is a very interesting implement.
Thanks and regards,
pingfan
On Thu, May 3, 2012 at 4:41 PM, Michael S. Tsirkin wrote:
> On Thu, May 03, 2012 at 04:33:55PM +0800, Liu ping fan wrote:
>> Hi,
>>
>> During reading the vhost-net code, I find the following,
>&g
Currently, the guest can not know the NUMA info of the vcpu, which will
result in performance drawback.
This is the discovered and experiment by
Shirley Ma
Krishna Kumar
Tom Lendacky
Refer to - http://www.mail-archive.com/kvm@vger.kernel.org/msg69868.html
we can see the
From: Liu Ping Fan
Make vhost allocate vhost_virtqueue on different host nodes as required.
Signed-off-by: Liu Ping Fan
---
drivers/vhost/vhost.c | 380 +++--
drivers/vhost/vhost.h | 41 --
include/linux/vhost.h |2 +-
3 files changed
From: Liu Ping Fan
For each numa node reported by vhost, we alloc a pair of i/o vq,
and assign them msix IRQ, and set irq affinity to a set of vcpu
in the same node.
Also we alloc vqs on PAGE_SIZE align, so they will be allocated by
host when pg fault happen on different node.
Signed-off-by
From: Liu Ping Fan
Vhost net uses separate transfer logic unit in different node.
Virtio net must determine which logic unit it will talk with,
so we can improve the performance.
Signed-off-by: Liu Ping Fan
---
drivers/net/virtio_net.c | 425 ++
1
From: Liu Ping Fan
Make vhost net support to spread on host node according the command.
And consider the whole vhost_net componsed of lots of logic net units.
for each node, there is a unit, which includes a vhost_worker thread,
rx/tx vhost_virtqueue.
Signed-off-by: Liu Ping Fan
---
drivers
On Sat, May 19, 2012 at 12:14 AM, Shirley Ma wrote:
> On Thu, 2012-05-17 at 17:20 +0800, Liu Ping Fan wrote:
>> Currently, the guest can not know the NUMA info of the vcpu, which
>> will
>> result in performance drawback.
>>
>> This is the discovered and ex
Currently, the guest can not know the NUMA info of the vcpu, which will
result in performance drawback. For example:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and push between these vcpus will cost more. But
unfortunately, currently, the guest is just blind to
From: Liu Ping Fan
The guest's scheduler can not see the numa info on the host and
this will result to the following scene:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and push between these vcpus will cost more. But
unfortunately, currently, th
From: Liu Ping Fan
A driver plays with Qemu's emulated "virt domain device". They aims to
export the host numa info to the guest.
--todo:
A more proper place to archive this driver?
Signed-off-by: Liu Ping Fan
---
drivers/virtio/Kconfig |4 ++
drivers/virtio/Makefile |
From: Liu Ping Fan
The guest's scheduler can not see the numa info on the host and
this will result to the following scene:
Supposing vcpu-a on nodeA, vcpu-b on nodeB, when load balance,
the tasks' pull and push between these vcpus will cost more. But
unfortunately, currently, th
1 - 100 of 129 matches
Mail list logo
