On 09/05/2012 03:02 PM, Jan Kiszka wrote:
> On 2012-09-05 13:25, Avi Kivity wrote:
>> On 09/05/2012 02:11 PM, Jan Kiszka wrote:
>>> On 2012-09-05 12:53, Avi Kivity wrote:
On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>
>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (an
On 2012-09-05 13:25, Avi Kivity wrote:
> On 09/05/2012 02:11 PM, Jan Kiszka wrote:
>> On 2012-09-05 12:53, Avi Kivity wrote:
>>> On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>
> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
> corresponding unref), which has the fol
On 09/05/2012 02:11 PM, Jan Kiszka wrote:
> On 2012-09-05 12:53, Avi Kivity wrote:
>> On 09/05/2012 01:36 PM, Jan Kiszka wrote:
My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
corresponding unref), which has the following requirements:
- if the refcou
On 2012-09-05 12:53, Avi Kivity wrote:
> On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>>
>>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
>>> corresponding unref), which has the following requirements:
>>>
>>> - if the refcount is nonzero, MemoryRegion::opaque is safe to use
On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>
>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
>> corresponding unref), which has the following requirements:
>>
>> - if the refcount is nonzero, MemoryRegion::opaque is safe to use
>> - if the refcount is nonzero, the Memory
On 2012-09-05 11:52, Avi Kivity wrote:
> On 09/05/2012 11:19 AM, liu ping fan wrote:
>> [...]
>>> We could externalize the refcounting and push it into device code. This
>>> means:
>>>
>>>memory_region_init_io(&s->mem, dev)
>>>
>>>...
>>>
>>>object_
On 09/05/2012 11:19 AM, liu ping fan wrote:
> [...]
>>>
>> We could externalize the refcounting and push it into device code. This
>> means:
>>
>>memory_region_init_io(&s->mem, dev)
>>
>>...
>>
>>object_ref(dev)
>>memory_region_add_subregion(...,
[...]
>>
> We could externalize the refcounting and push it into device code. This
> means:
>
>memory_region_init_io(&s->mem, dev)
>
>...
>
>object_ref(dev)
>memory_region_add_subregion(..., &dev->mr)
>
>...
>
>memory_regi
On Mon, Sep 3, 2012 at 6:06 PM, liu ping fan wrote:
> On Mon, Sep 3, 2012 at 4:52 PM, Avi Kivity wrote:
>> On 09/03/2012 10:44 AM, liu ping fan wrote:
>
If we make the refcount/lock internal to the region, we must remove the
opaque, since the region won't protect it.
On Mon, Sep 3, 2012 at 6:16 PM, Avi Kivity wrote:
> On 09/03/2012 01:06 PM, liu ping fan wrote:
>> On Mon, Sep 3, 2012 at 4:52 PM, Avi Kivity wrote:
>>> On 09/03/2012 10:44 AM, liu ping fan wrote:
>>
>
> If we make the refcount/lock internal to the region, we must remove the
> opa
On 09/03/2012 01:06 PM, liu ping fan wrote:
> On Mon, Sep 3, 2012 at 4:52 PM, Avi Kivity wrote:
>> On 09/03/2012 10:44 AM, liu ping fan wrote:
>
If we make the refcount/lock internal to the region, we must remove the
opaque, since the region won't protect it.
Replacing
On Mon, Sep 3, 2012 at 4:52 PM, Avi Kivity wrote:
> On 09/03/2012 10:44 AM, liu ping fan wrote:
>>>
>>> If we make the refcount/lock internal to the region, we must remove the
>>> opaque, since the region won't protect it.
>>>
>>> Replacing the opaque with container_of(mr) doesn't help, since
On 08/29/2012 08:41 PM, Jan Kiszka wrote:
>>>
>>> memory_region_transaction_commit (or calls that trigger this) will have
>>> to wait. That is required as the caller may start fiddling with the
>>> region right afterward.
>>
>> However, it may be running within an mmio dispatch, so it may wait for
On 09/03/2012 10:44 AM, liu ping fan wrote:
>>>
>>
>> If we make the refcount/lock internal to the region, we must remove the
>> opaque, since the region won't protect it.
>>
>> Replacing the opaque with container_of(mr) doesn't help, since we can't
>> refcount mr, only mr->impl.
>>
> I think you m
On Sat, Sep 1, 2012 at 4:46 PM, Avi Kivity wrote:
> On 08/30/2012 12:08 AM, Jan Kiszka wrote:
>> >>>
>> >>> We are dispatching according to the memory region (parameters, op
>> >>> handlers, opaques). If we end up in device object is not decided at this
>> >>> level. A memory region describes a di
On 09/01/2012 01:57 AM, Jan Kiszka wrote:
> On 2012-09-01 10:31, Avi Kivity wrote:
> > On 08/29/2012 10:49 AM, Jan Kiszka wrote:
> >>>
> >>> Let's experiment with refcounting MemoryRegion. We can move the entire
> >>> contents of MemoryRegion to MemoryRegionImpl, add a reference count (to
> >>> Me
On 2012-09-01 10:31, Avi Kivity wrote:
> On 08/29/2012 10:49 AM, Jan Kiszka wrote:
>>>
>>> Let's experiment with refcounting MemoryRegion. We can move the entire
>>> contents of MemoryRegion to MemoryRegionImpl, add a reference count (to
>>> MemoryRegionImpl), and change MemoryRegion to contain a
On 08/30/2012 12:08 AM, Jan Kiszka wrote:
> >>>
> >>> We are dispatching according to the memory region (parameters, op
> >>> handlers, opaques). If we end up in device object is not decided at this
> >>> level. A memory region describes a dispatchable area - not to confuse
> >>> with a device that
On 08/29/2012 10:49 AM, Jan Kiszka wrote:
> >
> > Let's experiment with refcounting MemoryRegion. We can move the entire
> > contents of MemoryRegion to MemoryRegionImpl, add a reference count (to
> > MemoryRegionImpl), and change MemoryRegion to contain a pointer to the
> > refcounted MemoryRegi
On Thu, Aug 30, 2012 at 3:08 PM, Jan Kiszka wrote:
> On 2012-08-30 07:54, liu ping fan wrote:
>> On Thu, Aug 30, 2012 at 1:40 AM, Avi Kivity wrote:
>>> On 08/29/2012 10:30 AM, Jan Kiszka wrote:
On 2012-08-29 19:23, Avi Kivity wrote:
> On 08/28/2012 02:42 AM, Jan Kiszka wrote:
>>
On 2012-08-30 07:54, liu ping fan wrote:
> On Thu, Aug 30, 2012 at 1:40 AM, Avi Kivity wrote:
>> On 08/29/2012 10:30 AM, Jan Kiszka wrote:
>>> On 2012-08-29 19:23, Avi Kivity wrote:
On 08/28/2012 02:42 AM, Jan Kiszka wrote:
>
> Let's not talk about devices or MMIO dispatching. I think
On Thu, Aug 30, 2012 at 1:40 AM, Avi Kivity wrote:
> On 08/29/2012 10:30 AM, Jan Kiszka wrote:
>> On 2012-08-29 19:23, Avi Kivity wrote:
>> > On 08/28/2012 02:42 AM, Jan Kiszka wrote:
>> >>
>> >> Let's not talk about devices or MMIO dispatching. I think the problem is
>> >> way more generic, and w
On 2012-08-29 19:40, Avi Kivity wrote:
> On 08/29/2012 10:30 AM, Jan Kiszka wrote:
>> On 2012-08-29 19:23, Avi Kivity wrote:
>>> On 08/28/2012 02:42 AM, Jan Kiszka wrote:
Let's not talk about devices or MMIO dispatching. I think the problem is
way more generic, and we will face it mu
On 2012-08-29 19:27, Avi Kivity wrote:
> On 08/29/2012 10:21 AM, Jan Kiszka wrote:
>> On 2012-08-29 19:13, Avi Kivity wrote:
>>> On 08/27/2012 06:01 PM, Jan Kiszka wrote:
On 2012-08-27 22:53, Avi Kivity wrote:
> On 08/27/2012 12:38 PM, Jan Kiszka wrote:
Even worse, apply
On 08/29/2012 10:30 AM, Jan Kiszka wrote:
> On 2012-08-29 19:23, Avi Kivity wrote:
> > On 08/28/2012 02:42 AM, Jan Kiszka wrote:
> >>
> >> Let's not talk about devices or MMIO dispatching. I think the problem is
> >> way more generic, and we will face it multiple times in QEMU.
> >
> > The proble
On 08/29/2012 10:21 AM, Jan Kiszka wrote:
> On 2012-08-29 19:13, Avi Kivity wrote:
> > On 08/27/2012 06:01 PM, Jan Kiszka wrote:
> >> On 2012-08-27 22:53, Avi Kivity wrote:
> >>> On 08/27/2012 12:38 PM, Jan Kiszka wrote:
> >> Even worse, apply
> >> restrictions on how the dispatched objects
On 2012-08-29 19:23, Avi Kivity wrote:
> On 08/28/2012 02:42 AM, Jan Kiszka wrote:
>>
>> Let's not talk about devices or MMIO dispatching. I think the problem is
>> way more generic, and we will face it multiple times in QEMU.
>
> The problem exists outside qemu as well. It is one of the reasons
On 08/28/2012 02:42 AM, Jan Kiszka wrote:
>
> Let's not talk about devices or MMIO dispatching. I think the problem is
> way more generic, and we will face it multiple times in QEMU.
The problem exists outside qemu as well. It is one of the reasons for
the popularity of garbage collection IMO, a
On 2012-08-29 19:13, Avi Kivity wrote:
> On 08/27/2012 06:01 PM, Jan Kiszka wrote:
>> On 2012-08-27 22:53, Avi Kivity wrote:
>>> On 08/27/2012 12:38 PM, Jan Kiszka wrote:
>> Even worse, apply
>> restrictions on how the dispatched objects, the regions, have to be
>> treated because of th
On 08/27/2012 06:01 PM, Jan Kiszka wrote:
> On 2012-08-27 22:53, Avi Kivity wrote:
> > On 08/27/2012 12:38 PM, Jan Kiszka wrote:
> Even worse, apply
> restrictions on how the dispatched objects, the regions, have to be
> treated because of this.
> >>>
> >>> Please elaborate.
> >>
> >
Il 28/08/2012 11:42, Jan Kiszka ha scritto:
> Context A Context B
> - -
> object = lookup()
> deregister(object)
> modify(object) -> invalid state
> ...
On 2012-08-28 05:38, liu ping fan wrote:
> On Tue, Aug 28, 2012 at 11:09 AM, liu ping fan wrote:
>> On Tue, Aug 28, 2012 at 3:38 AM, Jan Kiszka wrote:
>>> On 2012-08-27 20:52, Avi Kivity wrote:
On 08/27/2012 11:39 AM, Jan Kiszka wrote:
> On 2012-08-27 20:20, Avi Kivity wrote:
>> On 0
On Tue, Aug 28, 2012 at 11:09 AM, liu ping fan wrote:
> On Tue, Aug 28, 2012 at 3:38 AM, Jan Kiszka wrote:
>> On 2012-08-27 20:52, Avi Kivity wrote:
>>> On 08/27/2012 11:39 AM, Jan Kiszka wrote:
On 2012-08-27 20:20, Avi Kivity wrote:
> On 08/27/2012 11:17 AM, Jan Kiszka wrote:
>> On
On Tue, Aug 28, 2012 at 3:38 AM, Jan Kiszka wrote:
> On 2012-08-27 20:52, Avi Kivity wrote:
>> On 08/27/2012 11:39 AM, Jan Kiszka wrote:
>>> On 2012-08-27 20:20, Avi Kivity wrote:
On 08/27/2012 11:17 AM, Jan Kiszka wrote:
> On 2012-08-27 20:09, Avi Kivity wrote:
>> On 08/27/2012 10:14
On 2012-08-27 22:53, Avi Kivity wrote:
> On 08/27/2012 12:38 PM, Jan Kiszka wrote:
Even worse, apply
restrictions on how the dispatched objects, the regions, have to be
treated because of this.
>>>
>>> Please elaborate.
>>
>> The fact that you can't manipulate a memory region object
Il 27/08/2012 22:58, Avi Kivity ha scritto:
>> > It's best to start this conversion using very coarse locking. There's
>> > no need to start with ultra fine grain locking.
> How does it work? You have to drop this main loop lock to dispatch the
> callback, so the data structure you use for dispat
On 08/27/2012 12:17 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
> > On 08/27/2012 09:24 AM, Anthony Liguori wrote:
> >> >
> >> > I'm sure we should leave existing code alone wherever possible, focusing
> >> > on providing alternative versions for those paths that matter. Example:
> >> > Most
On 08/27/2012 12:38 PM, Jan Kiszka wrote:
> >> Even worse, apply
> >> restrictions on how the dispatched objects, the regions, have to be
> >> treated because of this.
> >
> > Please elaborate.
>
> The fact that you can't manipulate a memory region object arbitrarily
> after removing it from the m
On 2012-08-27 20:52, Avi Kivity wrote:
> On 08/27/2012 11:39 AM, Jan Kiszka wrote:
>> On 2012-08-27 20:20, Avi Kivity wrote:
>>> On 08/27/2012 11:17 AM, Jan Kiszka wrote:
On 2012-08-27 20:09, Avi Kivity wrote:
> On 08/27/2012 10:14 AM, Jan Kiszka wrote:
>>>
>>> Deregistration is fi
On 2012-08-27 21:17, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> On 08/27/2012 09:24 AM, Anthony Liguori wrote:
I'm sure we should leave existing code alone wherever possible, focusing
on providing alternative versions for those paths that matter. Example:
Most timers are
Avi Kivity writes:
> On 08/27/2012 09:24 AM, Anthony Liguori wrote:
>> >
>> > I'm sure we should leave existing code alone wherever possible, focusing
>> > on providing alternative versions for those paths that matter. Example:
>> > Most timers are fine under BQL. But some sensitive devices (RTC
On 08/27/2012 11:39 AM, Jan Kiszka wrote:
> On 2012-08-27 20:20, Avi Kivity wrote:
> > On 08/27/2012 11:17 AM, Jan Kiszka wrote:
> >> On 2012-08-27 20:09, Avi Kivity wrote:
> >>> On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> >
> > Deregistration is fine, the problem is destruction.
> >
>
On 2012-08-27 20:20, Avi Kivity wrote:
> On 08/27/2012 11:17 AM, Jan Kiszka wrote:
>> On 2012-08-27 20:09, Avi Kivity wrote:
>>> On 08/27/2012 10:14 AM, Jan Kiszka wrote:
>
> Deregistration is fine, the problem is destruction.
>
It isn't as you access memory region states that
On 08/27/2012 09:24 AM, Anthony Liguori wrote:
> >
> > I'm sure we should leave existing code alone wherever possible, focusing
> > on providing alternative versions for those paths that matter. Example:
> > Most timers are fine under BQL. But some sensitive devices (RTC or HPET
> > as clock source
On 08/27/2012 06:19 AM, Anthony Liguori wrote:
> Liu Ping Fan writes:
>
> > From: Liu Ping Fan
> >
> > Scene:
> > obja lies in objA, when objA's ref->0, it will be freed,
> > but at that time obja can still be in use.
> >
> > The real example is:
> > typedef struct PCIIDEState {
> > PCIDevi
On 08/27/2012 11:17 AM, Jan Kiszka wrote:
> On 2012-08-27 20:09, Avi Kivity wrote:
> > On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> >>>
> >>> Deregistration is fine, the problem is destruction.
> >>>
> >>
> >> It isn't as you access memory region states that can change after
> >> deregistration. Dev
On 2012-08-27 20:09, Avi Kivity wrote:
> On 08/27/2012 10:14 AM, Jan Kiszka wrote:
>>>
>>> Deregistration is fine, the problem is destruction.
>>>
>>
>> It isn't as you access memory region states that can change after
>> deregistration. Devices can remove memory regions from the mapping,
>> alter
On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> >
> > Deregistration is fine, the problem is destruction.
> >
>
> It isn't as you access memory region states that can change after
> deregistration. Devices can remove memory regions from the mapping,
> alter and then reinsert them. The last to steps m
On 2012-08-27 19:09, Avi Kivity wrote:
> On 08/27/2012 12:47 AM, Jan Kiszka wrote:
>> On 2012-08-27 09:01, Paolo Bonzini wrote:
>>> Il 25/08/2012 09:42, liu ping fan ha scritto:
>>
>> I don't see why MMIO dispatch should hold the IDEBus ref rather than the
>> PCIIDEState.
>>
Wh
On 08/27/2012 12:47 AM, Jan Kiszka wrote:
> On 2012-08-27 09:01, Paolo Bonzini wrote:
> > Il 25/08/2012 09:42, liu ping fan ha scritto:
>
> I don't see why MMIO dispatch should hold the IDEBus ref rather than the
> PCIIDEState.
>
> >> When transfer memory_region_init_io() 3rd p
On 2012-08-27 18:24, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> On 2012-08-27 17:14, Anthony Liguori wrote:
>>> Jan Kiszka writes:
>>>
On 2012-08-27 15:19, Anthony Liguori wrote:
> Liu Ping Fan writes:
>
>> From: Liu Ping Fan
>>
>> Scene:
>> obja lies in ob
Jan Kiszka writes:
> On 2012-08-27 17:14, Anthony Liguori wrote:
>> Jan Kiszka writes:
>>
>>> On 2012-08-27 15:19, Anthony Liguori wrote:
Liu Ping Fan writes:
> From: Liu Ping Fan
>
> Scene:
> obja lies in objA, when objA's ref->0, it will be freed,
> but at th
On 2012-08-27 17:14, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> On 2012-08-27 15:19, Anthony Liguori wrote:
>>> Liu Ping Fan writes:
>>>
From: Liu Ping Fan
Scene:
obja lies in objA, when objA's ref->0, it will be freed,
but at that time obja can still be in use.
Jan Kiszka writes:
> On 2012-08-27 15:19, Anthony Liguori wrote:
>> Liu Ping Fan writes:
>>
>>> From: Liu Ping Fan
>>>
>>> Scene:
>>> obja lies in objA, when objA's ref->0, it will be freed,
>>> but at that time obja can still be in use.
>>>
>>> The real example is:
>>> typedef struct PCIIDE
On 2012-08-27 15:19, Anthony Liguori wrote:
> Liu Ping Fan writes:
>
>> From: Liu Ping Fan
>>
>> Scene:
>> obja lies in objA, when objA's ref->0, it will be freed,
>> but at that time obja can still be in use.
>>
>> The real example is:
>> typedef struct PCIIDEState {
>> PCIDevice dev;
>>
Liu Ping Fan writes:
> From: Liu Ping Fan
>
> Scene:
> obja lies in objA, when objA's ref->0, it will be freed,
> but at that time obja can still be in use.
>
> The real example is:
> typedef struct PCIIDEState {
> PCIDevice dev;
> IDEBus bus[2]; --> create in place
> .
> }
>
>
On 2012-08-27 10:17, liu ping fan wrote:
> On Mon, Aug 27, 2012 at 3:47 PM, Jan Kiszka wrote:
>> On 2012-08-27 09:01, Paolo Bonzini wrote:
>>> Il 25/08/2012 09:42, liu ping fan ha scritto:
>>
>> I don't see why MMIO dispatch should hold the IDEBus ref rather than the
>> PCIIDEState.
>>
On Mon, Aug 27, 2012 at 3:47 PM, Jan Kiszka wrote:
> On 2012-08-27 09:01, Paolo Bonzini wrote:
>> Il 25/08/2012 09:42, liu ping fan ha scritto:
>
> I don't see why MMIO dispatch should hold the IDEBus ref rather than the
> PCIIDEState.
>
>>> When transfer memory_region_init_io() 3
On 2012-08-27 09:01, Paolo Bonzini wrote:
> Il 25/08/2012 09:42, liu ping fan ha scritto:
I don't see why MMIO dispatch should hold the IDEBus ref rather than the
PCIIDEState.
>> When transfer memory_region_init_io() 3rd para from void* opaque to
>> Object* obj, the obj : opaq
Il 25/08/2012 09:42, liu ping fan ha scritto:
>> >
>> > I don't see why MMIO dispatch should hold the IDEBus ref rather than the
>> > PCIIDEState.
>> >
> When transfer memory_region_init_io() 3rd para from void* opaque to
> Object* obj, the obj : opaque is not neccessary 1:1 map. For such
> situa
On Fri, Aug 24, 2012 at 10:42 PM, Paolo Bonzini wrote:
> Il 24/08/2012 11:49, Liu Ping Fan ha scritto:
>> With this patch, we can protect PCIIDEState from disappearing during
>> mmio-dispatch hold the IDEBus->ref.
>
> I don't see why MMIO dispatch should hold the IDEBus ref rather than the
> PCIID
Il 24/08/2012 11:49, Liu Ping Fan ha scritto:
> With this patch, we can protect PCIIDEState from disappearing during
> mmio-dispatch hold the IDEBus->ref.
I don't see why MMIO dispatch should hold the IDEBus ref rather than the
PCIIDEState.
In the case of the PIIX, the BARs are set up by the PCII
From: Liu Ping Fan
Scene:
obja lies in objA, when objA's ref->0, it will be freed,
but at that time obja can still be in use.
The real example is:
typedef struct PCIIDEState {
PCIDevice dev;
IDEBus bus[2]; --> create in place
.
}
When without big lock protection for mmio-dispa
63 matches
Mail list logo
