qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" st


From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH qemu v7 06/14] spapr_iommu: Introduce "enabled" state for TCE table
Date: Wed, 27 May 2015 01:49:08 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 05/27/2015 01:08 AM, Paolo Bonzini wrote:


On 26/05/2015 17:00, Alexey Kardashevskiy wrote:
Why do you need different regions?  Why can't you have always the same
IOMMU regions, and either:

They may change a size.

That's not a problem, there's memory_region_set_size for that.

It was not there when I started doing this DDW :) If so, I can keep the
existing structure and just set size to zero instead of
memory_region_del_subregion().

del/add_subregion is okay.  It's just init/unparent that is wrong.

Yup, right, my bad, I do not need init/unparent and I still need del/add_subregion for setting an offset.



I need windows appear and disappear on a bus dynamically, that's it. The
actual sPAPRTCETable objects exist always.

Great.

Aliases will do the job as far as I can tell.

Then you can choose between init_alias/add/del/unparent(alias) and
del/set_size/add which Michael has mentioned.  The latter is probably
cleaner and faster.

sPAPRTCETable stores the actual table and if I want it to migrate, the
destination QEMU must have the object created-and-vmstate_register'ated.
But the table (and class) may be absent or present on the source side so
I need to start the destination with or without -device sPAPRTCETable,
and if I need to create this object, I need to make it a child of a PHB
and last time I checked - there is no command line interface for linking
children.

Yup, understood now.

But I started thinking that always having 2 sPAPRTCETable objects (some
may be "disabled") it not better than a single sPAPRTCETable with
multiple TCE tables...

Whatever works best for you.  Either is okay.

Yeah... multiple sPAPRTCETables and set_size() it is then. A single sPAPRTCETable has a problem that if I need to migrate multiple tables - vmstate will look ugly (especially for backward compatibility).


--
Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]