- Messaggio originale -
> Da: "Avi Kivity"
> A: "Paolo Bonzini"
> Cc: "Liu Ping Fan" , qemu-devel@nongnu.org,
> "Anthony Liguori" ,
> "Marcelo Tosatti" , "Jan Kiszka"
> , "Stefan Hajnoczi"
>
> Inviato: Giovedì, 25 ottobre 2012 18:28:27
> Oggetto: Re: [patch v4 05/16] memory: introduc
On 10/24/2012 09:29 AM, Paolo Bonzini wrote:
> Il 23/10/2012 18:09, Avi Kivity ha scritto:
>>> But our interfaces had better support asynchronicity, and indeed they
>>> do: after you write to the "eject" register, the "up" will show the
>>> device as present until after destroy is done. This can b
Il 23/10/2012 18:09, Avi Kivity ha scritto:
>> But our interfaces had better support asynchronicity, and indeed they
>> do: after you write to the "eject" register, the "up" will show the
>> device as present until after destroy is done. This can be changed to
>> show the device as present only un
On 10/23/2012 05:26 PM, Paolo Bonzini wrote:
>>> Yes, that's the point of doing things asynchronously---you do not need
>>> to do everything within stop_machine, you can start canceling AIO as
>>> soon as the OS sends the hot-unplug request. Then you only proceed with
>>> stop_machine and freeing
Il 23/10/2012 16:49, Avi Kivity ha scritto:
> On 10/23/2012 02:32 PM, Paolo Bonzini wrote:
>> Il 23/10/2012 14:15, Avi Kivity ha scritto:
>>> On 10/23/2012 02:06 PM, Paolo Bonzini wrote:
Il 23/10/2012 14:02, Avi Kivity ha scritto:
> On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
>> Il 23
On 10/23/2012 02:32 PM, Paolo Bonzini wrote:
> Il 23/10/2012 14:15, Avi Kivity ha scritto:
>> On 10/23/2012 02:06 PM, Paolo Bonzini wrote:
>>> Il 23/10/2012 14:02, Avi Kivity ha scritto:
On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
> Il 23/10/2012 13:55, Avi Kivity ha scritto:
So
On 10/23/2012 02:40 PM, Jan Kiszka wrote:
> On 2012-10-23 14:28, Avi Kivity wrote:
>> On 10/23/2012 02:16 PM, Jan Kiszka wrote:
>>> On 2012-10-23 14:12, Paolo Bonzini wrote:
Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>
> So the stop_machine idea is thrown away?
>>>
>
On 2012-10-23 14:28, Avi Kivity wrote:
> On 10/23/2012 02:16 PM, Jan Kiszka wrote:
>> On 2012-10-23 14:12, Paolo Bonzini wrote:
>>> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
So the stop_machine idea is thrown away?
>>
>> IIRC I convinced myself that it's just as bad.
>
Il 23/10/2012 14:15, Avi Kivity ha scritto:
> On 10/23/2012 02:06 PM, Paolo Bonzini wrote:
>> Il 23/10/2012 14:02, Avi Kivity ha scritto:
>>> On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
Il 23/10/2012 13:55, Avi Kivity ha scritto:
>>> So the stop_machine idea is thrown away?
> IIRC I
On 10/23/2012 02:16 PM, Jan Kiszka wrote:
> On 2012-10-23 14:12, Paolo Bonzini wrote:
>> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>>
>>> So the stop_machine idea is thrown away?
>
> IIRC I convinced myself that it's just as bad.
>>> One tricky part with stop machine is that le
On 2012-10-23 14:12, Paolo Bonzini wrote:
> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>
>> So the stop_machine idea is thrown away?
IIRC I convinced myself that it's just as bad.
>> One tricky part with stop machine is that legacy code may trigger it
>> while holding the BQL,
On 10/23/2012 02:06 PM, Paolo Bonzini wrote:
> Il 23/10/2012 14:02, Avi Kivity ha scritto:
>> On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
>>> Il 23/10/2012 13:55, Avi Kivity ha scritto:
>> So the stop_machine idea is thrown away?
IIRC I convinced myself that it's just as bad.
>>>
>>> It
Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>> >>
>>> >> So the stop_machine idea is thrown away?
>> >
>> > IIRC I convinced myself that it's just as bad.
> One tricky part with stop machine is that legacy code may trigger it
> while holding the BQL, does not expect to lose that lock even for a
Il 23/10/2012 14:02, Avi Kivity ha scritto:
> On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
>> Il 23/10/2012 13:55, Avi Kivity ha scritto:
> So the stop_machine idea is thrown away?
>>> IIRC I convinced myself that it's just as bad.
>>
>> It may be just as bad, but it is less code (and less pe
On 2012-10-23 13:55, Avi Kivity wrote:
> On 10/23/2012 01:51 PM, Paolo Bonzini wrote:
>> Il 22/10/2012 11:38, Avi Kivity ha scritto:
>
> typedef struct MemoryRegionOps MemoryRegionOps;
> typedef struct MemoryRegion MemoryRegion;
> @@ -66,6 +67,8 @@ struct MemoryRegionOps {
>
On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
> Il 23/10/2012 13:55, Avi Kivity ha scritto:
>>> > So the stop_machine idea is thrown away?
>> IIRC I convinced myself that it's just as bad.
>
> It may be just as bad, but it is less code (and less pervasive), which
> makes it less painful.
It save
Il 23/10/2012 13:55, Avi Kivity ha scritto:
>> > So the stop_machine idea is thrown away?
> IIRC I convinced myself that it's just as bad.
It may be just as bad, but it is less code (and less pervasive), which
makes it less painful.
Paolo
On 10/23/2012 01:51 PM, Paolo Bonzini wrote:
> Il 22/10/2012 11:38, Avi Kivity ha scritto:
>>> >
>>> > typedef struct MemoryRegionOps MemoryRegionOps;
>>> > typedef struct MemoryRegion MemoryRegion;
>>> > @@ -66,6 +67,8 @@ struct MemoryRegionOps {
>>> >target_phys_addr_t add
Il 22/10/2012 11:38, Avi Kivity ha scritto:
>> >
>> > typedef struct MemoryRegionOps MemoryRegionOps;
>> > typedef struct MemoryRegion MemoryRegion;
>> > @@ -66,6 +67,8 @@ struct MemoryRegionOps {
>> >target_phys_addr_t addr,
>> >uint64_t data,
>> >
This pair of interface help to decide when dispatching, whether
we can pin mr without big lock or not.
Signed-off-by: Liu Ping Fan
---
memory.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/memory.h b/memory.h
index bd1bbae..9039411 100644
--- a/memory.h
+++ b/memory
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> This pair of interface help to decide when dispatching, whether
> we can pin mr without big lock or not.
>
> Signed-off-by: Liu Ping Fan
> ---
> memory.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/memory.h b/memo
21 matches
Mail list logo
